meerk40t / meerk40t

Hackable Laser software for K40 / GRBL / Fibre Lasers
MIT License
233 stars 62 forks source link

Simplify device listings and add longer ray5 #2656

Closed Laserology closed 2 weeks ago

Laserology commented 2 weeks ago

This PR simplifies the device listings to separate types better, and also adds the Longer Ray5 to the list - making it easier for newcomers to get set up. Most types of devices not under a specific product or category have been moved into a generic or firmware named category.

I've mostly removed the redundant "Family Priority" entry as we can sort by name instead to form more concise grouped listings.

Summary by Sourcery

Simplify device listings by reorganizing categories and removing redundant attributes, and add support for the Longer Ray5 device.

New Features:

Enhancements:

sourcery-ai[bot] commented 2 weeks ago

Reviewer's Guide by Sourcery

This pull request simplifies device listings by reorganizing the family categories and removing redundant "family_priority" entries. It also adds support for the Longer Ray5 device. The changes primarily affect the plugin files for various device types, including Newly, GRBL, Balor MK, Lihuiyu, Moshi, and Ruida controllers.

Class diagram for device family reorganization

classDiagram
    class Device {
        +String friendly_name
        +String extended_info
        +int priority
        +String family
        +List<Choice> choices
    }
    class Choice {
        +String attr
        +String default
    }
    note for Device "Removed family_priority attribute"
    Device --> Choice : has
    Device : +String family = "Newly CO2-Laser"
    Device : +String family = "Generic Diode-Laser"
    Device : +String family = "K-Series CO2-Laser"
    Device : +String family = "Ortur Diode-Laser"
    Device : +String family = "Longer Diode-Laser"
    Device : +String family = "Generic Fibre-Laser"
    Device : +String family = "Generic CO2-Laser"
    Device : +String family = "Generic UV-Laser"

Class diagram for Longer Ray5 addition

classDiagram
    class LongerRay5 {
        +String provider = "provider/device/grbl"
        +String friendly_name = "Longer Ray5 (GRBL)"
        +String extended_info = "Longer-branded 10w/20w grbl diode laser."
        +int priority = 21
        +String family = "Longer Diode-Laser"
        +List<Choice> choices
    }
    class Choice {
        +String attr
        +String default
    }
    LongerRay5 --> Choice : has
    LongerRay5 : +String attr = "label"
    LongerRay5 : +String default = "Longer-Ray5"
    LongerRay5 : +String attr = "has_endstops"
    LongerRay5 : +boolean default = false
    LongerRay5 : +String attr = "source"
    LongerRay5 : +String default = "diode"
    LongerRay5 : +String attr = "require_validator"
    LongerRay5 : +boolean default = false
    LongerRay5 : +String attr = "bedheight"
    LongerRay5 : +String default = "450mm"
    LongerRay5 : +String attr = "bedwidth"
    LongerRay5 : +String default = "450mm"

File-Level Changes

Change Details Files
Reorganized device family categories
  • Consolidated 'Older CO2-Laser' family into 'Newly CO2-Laser'
  • Renamed some generic families to be more specific (e.g., 'Generic Diode-Laser', 'Generic Fibre-Laser')
  • Created new families for specific brands (e.g., 'Ortur Diode-Laser', 'Longer Diode-Laser')
  • Unified 'K-Series CO2-Laser' family across different controllers
meerk40t/newly/plugin.py
meerk40t/grbl/plugin.py
meerk40t/balormk/plugin.py
meerk40t/lihuiyu/plugin.py
meerk40t/moshi/plugin.py
meerk40t/ruida/plugin.py
Removed 'family_priority' entries
  • Deleted all 'family_priority' keys from device configurations
  • Updated device sorting logic in devicepanel.py to use 'family' instead of 'family_priority'
meerk40t/newly/plugin.py
meerk40t/grbl/plugin.py
meerk40t/balormk/plugin.py
meerk40t/lihuiyu/plugin.py
meerk40t/moshi/plugin.py
meerk40t/ruida/plugin.py
meerk40t/gui/devicepanel.py
Added support for Longer Ray5 device
  • Created a new device configuration for Longer Ray5
  • Set friendly name, extended info, and default parameters for the device
meerk40t/grbl/plugin.py

Tips and commands #### Interacting with Sourcery - **Trigger a new review:** Comment `@sourcery-ai review` on the pull request. - **Continue discussions:** Reply directly to Sourcery's review comments. - **Generate a GitHub issue from a review comment:** Ask Sourcery to create an issue from a review comment by replying to it. - **Generate a pull request title:** Write `@sourcery-ai` anywhere in the pull request title to generate a title at any time. - **Generate a pull request summary:** Write `@sourcery-ai summary` anywhere in the pull request body to generate a PR summary at any time. You can also use this command to specify where the summary should be inserted. #### Customizing Your Experience Access your [dashboard](https://app.sourcery.ai) to: - Enable or disable review features such as the Sourcery-generated pull request summary, the reviewer's guide, and others. - Change the review language. - Add, remove or edit custom review instructions. - Adjust other review settings. #### Getting Help - [Contact our support team](mailto:support@sourcery.ai) for questions or feedback. - Visit our [documentation](https://docs.sourcery.ai) for detailed guides and information. - Keep in touch with the Sourcery team by following us on [X/Twitter](https://x.com/SourceryAI), [LinkedIn](https://www.linkedin.com/company/sourcery-ai/) or [GitHub](https://github.com/sourcery-ai).
Laserology commented 2 weeks ago

Your method will create a different sequence of devices if a different language than English is chosen. That was the reason why we added a specific sort key to ensure a defined sequence regardless of the langage settings. So I would advise to keep the family_priority key.

Not that we have translations now - but how about we sort names first, and then apply translations afterwards, effectively keeping the ordering? Re-sorting only gets triggered manually it appears.

Laserology commented 2 weeks ago

Your method will create a different sequence of devices if a different language than English is chosen. That was the reason why we added a specific sort key to ensure a defined sequence regardless of the langage settings. So I would advise to keep the family_priority key.

Not that we have translations now - but how about we sort names first, and then apply translations afterwards, effectively keeping the ordering? Re-sorting only gets triggered manually it appears.

I do suggest we keep sorting by names anyways because sorting by a manually entered number becomes messy and a hassle for maintaining the code very quickly.

jpirnay commented 2 weeks ago
Laserology commented 2 weeks ago
  • Probably a bit of a personal preference - Labels are not necessarily providing a good sorting criteria - so is a GRBL better placed before a K40 or a Lihuiyu device?
  • A translation afterwards is a bit messy, as we have a couple of external tools for the translators that look for a _("Something to translate") occurence (specifically for the _( invocation).
  • We have translations for the family types: grafik grafik grafik

I was not aware, thanks for pointing that out.

Family priority still feels quite clunky.

After translating, do the internal names still remain the same? Or do they change?

How about, when translating, adding an extra field 'family_translated', so that the normal family name can still be used for sorting? For displaying, just check if translated exists for that device, if so, use that for display name, if not, then use the normal family name.

Laserology commented 2 weeks ago

As for order of names, it's reverse alphabetical, so grbl/generic goes AFTER K-series and others

Laserology commented 2 weeks ago
  • Probably a bit of a personal preference - Labels are not necessarily providing a good sorting criteria - so is a GRBL better placed before a K40 or a Lihuiyu device?
  • A translation afterwards is a bit messy, as we have a couple of external tools for the translators that look for a _("Something to translate") occurence (specifically for the _( invocation).
  • We have translations for the family types: grafik grafik grafik

I was not aware, thanks for pointing that out.

Family priority still feels quite clunky.

After translating, do the internal names still remain the same? Or do they change?

How about, when translating, adding an extra field 'family_translated', so that the normal family name can still be used for sorting? For displaying, just check if translated exists for that device, if so, use that for display name, if not, then use the normal family name.

What about a mapping function for priority? Instead of defining family priority in the device entry, it could be sorted based on family name inside of a map, like so:

Family 1 -> priority 5 Family 2 -> priority 30 [ Etc... ]

jpirnay commented 2 weeks ago

What about a mapping function for priority? Instead of defining family priority in the device entry, it could be sorted based on family name inside of a map, like so:

Family 1 -> priority 5 Family 2 -> priority 30 [ Etc... ]

I think that could make sense.

Laserology commented 2 weeks ago

What about a mapping function for priority? Instead of defining family priority in the device entry, it could be sorted based on family name inside of a map, like so: Family 1 -> priority 5 Family 2 -> priority 30 [ Etc... ]

I think that could make sense.

That should do it.