Yes, you are correct.
@mlac I agree with @likern, please donāt implement keyloggers and collect data. There would be major privacy implications from it.
@kareltucek As far as the subject of this post, it is my humble opinion, that these types of issues and a lot of other issues would be fixed if the documentation was written in a way so that even a five year old could understand it. With more three or more examples/gifs of what each feature does and samples the user can copy and paste into a macro to preview every feature of the keyboard. Also, with more accessible information, the user could easily search for a given problem or know about it ahead of time, and easily decide how they want to fix it.
btw, this keyboard rocks! thank you all for all the hard work!
2 Likes
@jello regarding subject of this post, I am not convinced that people are going to read the entire documentation before starting to use the keyboard just in case something goes wrong for unclear reasons, especially not if it is written as if for a five year old (and therefore terribly long and containing mostly uninteresting information).
Keep in mind that the issue discussed in this post affects normal popover actions as well (like the mentioned shift+9 or primary action of a secondary role key), not just macro commands.
As a sidenote, yes, documentation definitely can be improved. Please do suggest specific changes, or write them yourself and post a PR. (Stating just that it is bad and needs to get generally better is not very helpful. Seen that before. But not many actually bothered to write down what exactly is bad and needs to be improved.)
1 Like
@kareltucek Yes, I will keep that in mind to write PRās. It would be hard for me to rewrite sections I donāt understand. Maybe this is why otherās havenāt tried to rewrite?
Just a quick look through the user guide Iāll point out one section I canāt seem to make sense of, the 'Advanced Keybinding Topics ā area.
Iāve never written macros before UHK so maybe that would help? But when it gets to the ācontrol flowā statements, I get that they can be used, but donāt understand scenarios where it could be useful?
Also have trouble understanding why Iād need āAdvance Commandsā since the example given, states " yes, this is a totally meaningless example "
Also I donāt see any sections specifically for Mac, Linux, or Windows, telling the user how the keyboard reacts differently. It might be a great place to put things like what your wrote in the first post of the thread
ā * When actions are sent over different USB interfaces they often arrive in wrong order. For example Ctrl + mouse click. (This is probably a problem with Windows. I canāt reproduce this on Linux. More info needed.)
ā * Linux ignores mouse releases shorter than ~15 ms. Probably to cover up switch malfunctions or bouncing. This is a problem for touchpad doubletap and doubletap-to-hold features since touchpad needs to prolong presses to distinguish and properly apply these two actions. Currently, we add artificial delay of 20ms to solve this problem.
@jello, all great points!
Yeah, I see, although specifying what is wrong is the far more important part than actually posting PRs
Which parts exactly?
Will fix that. (I too couldnāt think of a usecase at the time 
.)
Fair point, will fix that.
The trouble here is that we didnāt do much research on this, so above are not facts. They are just vague suspicions.
But yeah, I can write a new section dedicated to āknown software interaction troublesā.
@jello I tried to clarify some things, you can find the edited document at WIP: Docs improvements by kareltucek Ā· Pull Request #116 Ā· kareltucek/firmware Ā· GitHub or https://github.com/kareltucek/firmware/blob/docs_improvements/doc-dev/user-guide.md
Feel free to comment on them (you should be able to do so comfortably in the pull request). (I will clean them up and merge eventually.)
yes, thatās perfect. thankyou so so much for doing that