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
Module configuration UI #1921
Comments
According to the latest blog posts, there are such plans. Feel free to share your designs. |
I think the question here is whether these should be implemented under the Modules (currently not visible in UI) as their own pages to configure the "default" functionality or if this should be somehow tied to the Keymaps instead considering macros and keymap changes can reconfigure them. One idea how it could work is that e.g we have a side menu that looks like this like it already exists in code:
Opening these shows sliders like the Mouse Key Speed page or the smart macro docs. These configure the default functionality (I guess like the I guess at least these pages should also contain things like disabling some features (e.g double tap to drag for Touchpad or tiny trackball for Key cluster). |
I'd put cogwheel icons near the modules. By clicking one, Agent would jump to the modules -> $currentModule page. I'd only show the pages of the mounted modules in the sidebar. On module pages, I'd expose every option currently featured in the smart macro sidebar, which includes general module options and module-specific options. I don't want to introduce further options for now, such as disabling double tap to drag. Disabling the mini trackball of the key cluster is possible via navigation modes. I agree that these settings should affect the default behavior of modules. Per-keymap behavior can be achieved via smart macros. |
Hi! Is it possible to swap direction to "natural" (apple-like) for minitrackball in keycluster module with new UHK agent UI and firmware? If smart macros are the way, are there some examples to start from scratch and a macros reference guide? |
Current UI mockup: The puzzle buttons lead to the relevant module pages, also accessible in the side menu: @laxu Would you be interested in creating mockups for the module pages? I'm quite busy nowadays and interested in what you come up with. |
I'm afraid I have been also extremely busy this year so I haven't had any time to work on this stuff. I will have to see if I have some time over Christmas or early next year. |
Module configuration page mockup: The "Key cluster settings" and "Touchpad settings" sections should only be shown on the pages of respective modules. The layout is inaccurate. Implement the layout according to the following:
|
Related PR: UltimateHackingKeyboard/firmware#737 |
(All the secondary role settings are for the advanced strategy only, so it seems like a good idea to me to gray them out when "Simple" is checked.) |
@kareltucek Exactly my thoughts, and I was going to ask you about it. Any further grayouts? For example, should we also gray out "double tap timeout" when "double tap to primary" is unchecked? |
Makes sense. Yes. |
Also a slight problem is that the "Double tap to lock layer timeout" also controls smart macro "ifDoubletap" condition... which is not at all clear from the UI. |
@kareltucek How about clarifying it in the smart macro documentation? |
But then we'd have two "double tap timeout" options, which I find confusing, even if they're in different sections. |
Hi @kareltucek, Laszlo recommended asking you about the Typing behaviour screen. What are the tooltip texts? What are the min, max, step and default values of the slider components?
When the simple resolution strategy selected of the secondary roles should I reset the values besides greying them or I can leave them as they are? |
Please leave them as they are. Do you need similar information for some of the other screens? @mondalaci as a sidenote, I am wondering if we should somehow retain control over the default values of some of the properties (especially the Keystroke Delay) unless the user deliberately specifies them. E.g., the dictionary method used for modules has the benefit that if the user does not adjust a value and consequently agent does not write it into the config, and we update the defaults, the user gets the benefit of the updated default. |
@kareltucek Agent will always write these properties to the user configuration for the sake of simplicity, so Agent's default values should reflect firmware defaults. I'm unsure what you mean by retaining control, but the above hopefully answers your question. |
I mean that if the user does not deliberately choose his preferred value, and we choose to change our default, it would be nice if that user's value changed to the new default too. (But yeah, above answers the question.) |
Gotcha. I think that we should seldom change defaults because the user might dislike the new default and be unaware of the change. And to reiterate, it's easier for Agent to always set properties. |
@kareltucek thanks for the collection.
I tried to collect them from the smart macro doc and I asked Laci too. But I haven't found all information yet, so if you could create the same table for other screens/fields would be a big help for me. THX |
As for default values:
Special behaviors:
Generally the steps are quite arbitrary, feel free to adjust them if it seems reasonable. Also, don't be alarmed that mins/maxs don't match the docs. The firmware accepts anything that fits the target types, so the only point of having them is to guide the user as to what a reasonable value is. |
awesome, thx |
Done by #2166 |
Now that Agent allows you to configure module settings using Smart Macros, are there plans to add easy UI pages to configure all this stuff?
If yes, are there any designs for these? I might have some time to implement some UIs.
The text was updated successfully, but these errors were encountered: