Open mhantsch opened 2 weeks ago
What about instead of introducing a complex system of variables, we introduced just a condition that would allow distinguish specific UHK based on its name? Sounds much simpler and yet still more versatile.
As for connected module, there is ifModuleConnected
already.
@kareltucek Please provide an example smart macro code for the proposed solution.
What about instead of introducing a complex system of variables, we introduced just a condition that would allow distinguish specific UHK based on its name? Sounds much simpler and yet still more versatile.
Would be very versatile, but maybe too versatile? It would not help with firmware versions, and I would kind of map names to specific features (ISO vs. ANSI, v1 vs. v2) instead of being able to determine each feature directly. I would end up having something like this in the macro code:
if regExMatch($uhk.name, /v1/) ... // it's a v1 UHK
if regExMatch($uhk.name, /ISO/) ... // it has an ISO key
and now I need a regExMatch() function... :smirk: and I need to name my boards something like "My old UHK v1 ISO" and "My new UHK v2 ANSI";
or I use arbitrary names and I need to put that name => feature mapping into the code:
// calculate features of this keyboard
if $uhk.name = 'My old UHK' {
set uhk_version = 1 // is a UHK v1
set uhk_iso = 1 // and has an ISO key
} else if $uhk.name = 'My new UHK' {
set uhk_version = 2 // is a UHK v2
set uhk_iso = 0 // and has no ISO key
}
If I shared my configuration for others to use, it would not work out of the box. These other user would need to add their names and how they map to the hardware features on their UHKs.
As for connected module, there is
ifModuleConnected
already.
Ah, true. I had overlooked that.
No, we are not going to match regexes.
ifUhkName myFirstAndBelovedUhk set leds.enabled 1
I'm very much against inflating commands, especially for such niche features. Adding namespaced $hardware.*
variables make far more sense to me.
Well, since a user may want to distinguish two units of the same keyboard, iffing on name is necessary... and that means adding strings (or more precisely, string references) as a variable type. That's possible, no problem...
So could you (@mondalaci) list the content of the new namespace? Where should name be placed in the structure? $uhkName
, or $uhk.name
, or $hardware.name
?
@kareltucek I think the names originally proposed by @mhantsch are reasonable. Please list the new variables accordingly, along with some examples of the full syntax they'd be used in smart macros.
So...
if $hardware.layout.isoKey == 1 ...
if $hardware.model == Uhk60v1 ...
if $firmware.version.major >= 2 ...
if $firmware.version.minor >= 2 ...
if $firmware.version.patch >= 2 ...
if $hardware.attachedModule.trackpoint ...
if $uhk.name == "my uhk" ...
Thanks, looks good!
No, it does not. Model is missing from the list. It means that furthermore, we will have to have enum values for UHK60v2, ...
Now this sounds reasonable.
I want to use the exact same configuration on multiple UHKs, which have different configurations (ISO vs. ANSI layout, modules attached, UHK60 v1 vs. UHK60 v2, possibly running different firmware versions...). I would like to query these data from my macros, so I can adapt some of the behaviour depending on the hardware.
Could there be some system variables that provide that information?
Something like: