Ideas, opinions?
(Post must be at least 20 characters long.)
Yes, I have an opinion. I’d place it on the top line of the display, between the connection status on the left (the one that shows whether bridge cable or NUS is used between the halves), and the other indicators further on the right (Caps Lock, Num Lock, …). I think there should be enough room to place three characters in a reasonably small font.
1 Like
Well, in case of the Oled we can definitely afford more than three characters if we have enough space for them 
.
What if you move the battery indicator to be between the NUS/Bridge icon and CAPS/Num Lock indicators, and then place the device connection type to the right of all that. And limit the device connection to only display “Host: USB, DGL#xx, BLE#xx”.
EDIT: You could probably even get away with limiting the device connection to “USB, Dxx, Bxx”
Maybe add some dim ghost dividers between the top line indicators for clarity.
Then you’d have the entire bottom line (under the keymap title) free.
1 Like
I’d keep it compatible with the UHK60 and only allow 3 characters. It would also show the keymap abbreviations there. Really, exactly the same as the UHK60 display.
If you wanted, you could also make a second command that can set longer strings on the main part of the UHK80 display (maybe setOledDisplayTxt or just setDisplayTxt).
2 Likes
That’s a good idea.
I do think you could fit a lot more of the basic info in the top line though.
Something like:
L100% 🛜 R100% | A 1 | Host: USB
Probably just a dream, but…
- If there is a
setLongLedTextor something, I wonder if it could work on the 60, too? It could run the characters across the display like a ticker.
For backwards compatibility…
- The command for the longer text could take an optional last parameter for a 3 character string.
- The command could be written to display just the first 3 characters if executed on the 60. Example:
setLedText 2000 "SP+ Increasing Pointer Speed"would display “SP+”.
Placement…
- I don’t have an 80, yet, but in the in-store pictures, it looks like the middle row is where this text was intended to go. 3 character strings from the existing
setLedTextcommand should go to the same place, wherever it ends up, to keep it simple. - Temporary messages could display differently, like how Android Toast notifications display over app content for visibility, but are generally non-intrusive. If temporary:
- Maybe display with a solid lit background and black text to make the change more visible in peripheral vision.
- Maybe place across top or bottom of display?
1 Like
I’d allow a long string and make the UHK 60 truncate it to 3 characters.
I’d also add an optional last target parameter to specify whether to use the keymap name or the connection name field for this purpose, which would be ignored on the UHK 60.
Eventually, I’d allow users to construct a custom OLED screen layout containing a set of widgets. A widget would contain x, y coordinates, and a type. A type would be connectionIndicator, chargingPercentages, keymapName, customText1, and such. customText* could be specified as a target of setLedTxt, allowing multiple customizable fields.
2 Likes
That’s ugly if you want the same configuration to work on UHK60 and UHK80. It means I would always have to prefix the string with three-character acronyms (so they display something meaningful on the UHK60), and those abbreviations would always show on the UHK80.
Example strings:
CMK: Colemak Keymap
KEY: key pressed
DBL: double-press
MAX: Maxtend layer
123: Number pad
H++ Homerow Mods activated
H± Homerow Mods Auto-Mode
On the UHK80, you don’t really need those three-letter acronyms at the start of every message but they have to be there so the message makes sense on the UHK60.
That’s why I think there should be separate macros to set the UHK60 LED text vs. the UHK80 long string. I could do:
setLedTxt 500 MAX
setDisplayTxt 500 "Maxtend layer"
and each keyboard would get the best version to display and ignore the other command.
Or allow two text parameters for the setLedTxt command, e.g.
setLedTxt 500 MAX "Maxtend layer"
UHK60 would use the first text parameter (“MAX”) and the UHK80 would use the second (“Maxtend layer”).
Alternatively, I’d want a way to check which keyboard the macro is running on, e.g.:
if $hardware.$type == "UHK60" setLedTxt 500 MAX
if $hardware.$type == "UHK80" setLedTxt 500 "Maxtend layer"
but two separate commands make the macros substantially shorter.
And if you have separate commands, the three letters from setLedTxt could also be shown somewhere in an otherwise unused area of the UHK80 display.
With regards to widgets: Why not make setDisplayTxt take parameters in the string that would be replaced with certain element including formatting and/or icons, e.g.
setDisplayTxt 0 line 1 "%{left}%{interhalvesconnecticonicon} %{lcdtext} %{center}%{capslockicon}%{numlockicon}%{right}{hostconnectionicon}%{batteryleft} %{batteryright}"
setDisplayTxt 0 line 2 "%{center}%{keymap}"
setDisplayTxt 0 line 3 "%{center}%{hostconnection}"
3 Likes
Alternatively, I’d want a way to check which keyboard the macro is running on, e.g.:
We do plan to expose the information in similar fashion. I prefer this way to creating a special command.
With regards to widgets: Why not make
setDisplayTxttake parameters in the string that would be replaced with certain element including formatting and/or icons, e.g.
Will think about it. Exposing icons shouldn’t be a problem. Alignment is a bit more complex issue.
What about the two-string-parameters version of setLedTxt? I’d prefer avoiding the scattering of if $hardware... statements all over the macros everywhere where I want to set a text.
1 Like
I tend to dislike it as it increases complexity of the implementation as well as parsing and grammar. In any case, it is a detail, which I may in the end implement one way or another, or you may easily implement on your firmware fork.
setLedTxt 0 abbrev MAX "Maxtend layer"
I don’t intend to create my own forkware.
setLedTxt 0 abbrev MAX "Maxtend layer"
This actually sounds great!
I don’t intend to create my own forkware.
So, the suggestion would then be:
If there’s no abbrev keyword, then the first three characters of the (long) string are used for the UHK60 display (converted to uppercase). If there’s the abbrev keyword, then the parameter after the keyword is used for the UHK60 display. In any case, the whole (long) string is used for the UHK80.
Thus:
| command | UHK60 display | UHK80 display |
|---|---|---|
setLedTxt 0 MAX |
MAX |
MAX |
setLedTxt 0 "Extend layer by maexxx" |
EXT |
Extend layer by maexxx |
setLedTxt 0 abbrev MAX "Extend layer by maexxx" |
MAX |
Extend layer by maexxx |
setLedTxt 0 abbrev ABR "abbrev" |
ABR |
abbrev |
setLedTxt 0 "abbrev" |
ABB |
abbrev |
setLedTxt 0 abbreviated |
ABB |
abbreviated |
setLedTxt 0 abbrev |
(parse error) | (parse error) |
Doable with current parser (especially the last part with the (long) string containing “abbrev”)?
3 Likes
Yes, sounds like we are on the same page.
3 Likes