-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
determining hardware configuration of UHK from macros #780
Comments
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 |
@kareltucek Please provide an example smart macro code for the proposed solution. |
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:
and now I need a regExMatch() function... 😏 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:
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.
Ah, true. I had overlooked that. |
No, we are not going to match regexes.
|
I'm very much against inflating commands, especially for such niche features. Adding namespaced |
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? |
@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...
|
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:
The text was updated successfully, but these errors were encountered: