This was roughly the basic idea - of course it would need some icons and possibly colors etc.:
But the alignment/sizing in Tk is not really pixel perfect (is the padding the problem?). Especially the instrument control screen tends to expand a few pixels wider than the other screens.
Hi @wanthalf !
This looks promising, but:
Also, take a look to RGB led management. You could use it for replicating the color logic in your buttons. It shouldnāt be difficult.
Regards!
Yeah. This was just a proof-of-concept. I wanted to see it in this crazy āoverloadedā layout first. I have only done minimal necessary changes to the code (e.g. the sizes of the title bar and the onscreen buttons are still computed from the full screen dimensions, not the reduced one).
And I still have to find out which CUIA commands I should bind it to. Can I bind it directly to the logic of the corresponding buttons, so that even the āAltā switching logic would apply automatically? Or do I have to implement the logic myself?
With RGB LED management you mean the zynthia_wsleds_... classes? I have yet to find the system there as well. Make a new class that would change the colour of the onscreen widgets instead of physical LEDs?
Put a ā-ā line between each row of text on buttons. Or maybe better, only show the relevant text, i.e. show āOptā unless Alt is asserted in which case show āMenuā.
I really like this approach, difference in the cost of different size DSI screens with capacitive touch is minimal these days. This would remove a need for mcp chips and additional 4 encoders and switches can be wired directly to rpi.
I have always been a fan of encoders, but I have to admit that while playing with the touchscreen, I actually find things easier to find out intuitively, easier to remember and possibly even easier to use to control the thing.
But I suppose it also depends on the quality of the encoders. The cheap ones I bought from Ali feel rather hard/harsh to press and not so smooth to turn either as one is used from some audio receivers and similar profi devices.
We should still have 4 encoders on the right. They are still the best for a quick movement of options in the menu or adjusting synth parameters.
If this layout is going to be adopted (supported) next mini version will be based on it.
Of course, of course, fancy icons, fancy colours, bars, changing colours, changing labelsā¦ At the moment, I am still trying to find a list of the CUIA commands or their mapping to the physical V5 keys. 
When already speaking about the design, there are of course many different details to decide. I have both a left and right hand side layout, but I am not sure about other things: do we need to change colours like on the buttons if we can change the labels? Do we want to display and switch just the currently active (main/alt) label or both? We can also display both and highlight the active one (using a colour?). Or anything else. Or let the users decide and configure by their own preference 
In regards of layout I would suggest to try to use only left and bottom side. Keep right free for main app to render controls so that they are on the same side where encoders are.
In regards of colour try to emulate the same led colours of physical buttons on V5 so that the same tutorials can be used.
Keep right free for main app to render controls so that they are on the same side where encoders are.
Yes, thatās the main reason I prefer the left side layout in the end as well. At least as long as one is right-hander and has the encoders really located on the right side of the display Anyway, it can be currently switched by a single option.
In regards of colour try to emulate the same led colours of physical buttons on V5 so that the same tutorials can be used.
That is one idea. But the display and the buttons have different possibilities, advantages and disadvantages that should be taken into consideration. Emulating one exactly by the other is not always the best solution - and not necessary either. If the behaviour is clear enough, you donāt need to write a separate tutorial and anyone with an IQ higher that 0.0 will get it immediately. E.g. changing labels are much easier to grasp and understand than just changing colours where you need to remember what the colours actually mean.
So, on the screen the colours are more a decoration than indication. The current UI only uses a modest choice of grey or black background, and white, red or green foreground, I think. We can either make the onscreen keypad fit the rest of the UI or mimic the more fancy V5 keypad design.
I agree, however what is on v5 should be starting point and simplest to get designed and working. Simplest is often the best. It is easier to discuss how to enhance existing design than to start from scratch. Later will take much longer.
Have in mind that we need to test usability of this approach by real users. The sooner we get this available as configuration option the more real testing and feedback we can get. First release does not need to be perfect.
Simplest on buttons does not mean simplest on screen. Usually it is the opposite. Indicating change of function by means of colour is rather a complication (and on a screen rather pointless) both for the developer and user.
Well, anyway: I love using colours and I love to create configurable and customizable user interfaces, so I am all in for all options!
You can see these in webconf. If you configure your machine to have 20 custom switches, e.g. -1,-1,-1... then save and webconf HARDWARE page should show the configuration of each button, based on the selected profile.
Regarding button positioning - you may wish to consider a row of buttons along both bottom and top edges. The touch control of (encoder) controls is up/down swipe gestures. Having buttons on both borders may allow over-swipe to give more range on the controls near the edge.
You can see these in webconf. If you configure your machine to have 20 custom switches
Okā¦ Canāt I just find it in the source codes (if not the wiki yet)?
you may wish to consider a row of buttons along both bottom and top edges
I am not sure I get this correctly. You mean one row at the top, one at the bottom and the rest on the side? That would make up to 24 buttons (at equal size) and the main frame inbetween would be really very wide and very low on heightā¦ a kind of noodle? I think the 16:9 aspect ratio is impractical more than enough - I probably donāt make it much better with the two columns of buttons on the side, but taking even more of the scarce vertical space would make it even worse.
What can I possibly say butā¦Press thisā¦
I think that @riban ment you can use top side too to align buttons.
Look at how zynthian mini uses top, left and bottom sides. I am not suggesting to use the same layout. Zynthian Mini pcb and rpi position introduces a lot of limitations where buttons can be placed because the same PCB space is shared for buttons, midi and audio connectors etc.
Note that most āpointer-lessā user interfaces (aka, no mouse, no trackball, etc.) try to avoid buttons on top the display because your hand cover the display contents while pushing them, so you donāt have a good feedback of your actions. IMHO, buttons and other actuators should be around the display but not on top.
My 2 cents 
Just to answer a few of my own question:
sort zynthian-sys/config/zynthian_envars_V5.sh | grep ZYNTHIAN_WIRING_CUSTOM_SWITCH_ | grep -P '__UI_(ALT_)?(PUSH|SHORT|BOLD|LONG)' (OK, it could be just enough without the second grep)Another interesting observation: setting wiring profile (not the display!) to V5 makes the touch control broken (adapted to the V5 touchscreen?). Setting it back to custom does not solve the problem completely - I can navigate, but not trigger any action (not even the ābackā button on the title bar). The only solution: replace current zynthian_envars.sh with the zynthian_envars_backup.sh.
And one more interesting technical detail: an issue in the zyngui may cause the webconf to crash at start, despite the fact the zyngui itself works! (Probably result of some āimportā?)