Closed Laserology closed 2 weeks ago
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.
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"
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"
Change | Details | Files |
---|---|---|
Reorganized device family categories |
|
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 |
|
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 |
|
meerk40t/grbl/plugin.py |
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.
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.
_("Something to translate")
occurence (specifically for the _(
invocation).
- 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:
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.
As for order of names, it's reverse alphabetical, so grbl/generic goes AFTER K-series and others
- 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:
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... ]
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.
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.
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: