Touchscreen widgets

I have committed a couple of fixes to the branch to fix button height and press timer. I played with it a bit and am not yet convinced it is the best solution, especially as the button labels don’t necessarily portray their action (as described by @steveb above who suggests a future enhancement to make them context sensitive). I also note that only screens derived from the base class will inherit the buttons. That probably makes sense but not all screens may have been ported to use this base class. Also the buttons are set to row 3 of the grid which means all child panels must exist in rows 1 & 2. This may be fine if we ensure all child panels instigate their own background frame. (If we hit problems we could always make the button row higher - tkinter ignores empty rows.)

The button timers could be improved to give similar behaviour to buttons, i.e. long press should trigger without letting go of button.

The button timers could be improved to give similar behaviour to buttons, i.e. long press should trigger without letting go of button.

Absolutely. Panics alone justify this aspect…

Wow, This is exactly what I was thinking that is missing from UI when one has no encoders. Any chance to add Home button and Up/Down buttons also for navigating middle list panel? Those doesn’t need to be such wide, of course. Touching, holding and dragging past visible items is real PITA. And while I’m here, any future plans for change those circular values indicators for something different, squary maybe, High contrastish, something like progress bar in rectangular frame? Will save a lot of space on screen. Looking forward to continue my zynthian fiddlings with this new UI enhancements. How to get this on my zynth?

Edit: I’ve reread this thread, and if timed buttons are possible, Home/Back could reside on single button (Home on long press).

1 Like

I would rather the list widget behave like ubiquitous phone interfaces, so that swiping up scrolls down with gradually reducing momentum. I don’t know if tkinter supports this natively.

1 Like

Thanks, the buttons take the vertical space now

Agreed, this would be desirable

Its cumbersome on my display to swipe. As I said, it’s pita to scroll past visible list items. I would be happy to have it :slight_smile: Could be smaller with icons. Six items will fit nicely I believe. Those cornered ones could be also smaller as hitting corner somehow will survive some finger misalligments.

Swipe gestures are not supported by tkinter. There was some suggestion of looking at another GUI framework that does support gestures but I am not sure that has gone anywhere. Anyway, gestures only really work on capacitive touch screens. Resistive screens tend to require even pressure which is not easy nor natural when swiping. Also, gestures become more awkward on smaller screens. I believe out core goal is to provide a consistent interface for the majority of users with minimal maintenance overhead, concentrating on the official hardware but supporting other hardware where practicable. There are lots of fun things we could do with display x/y/z but I am sure poor @jofemodo doesn’t want the technical debt of a hundred good ideas abandoned by good-willed contributors who’s lives have demanded they move on to other things… (I have been one of those on many projects!!! I have stuck around here for a while though.)

I’ve re-styled a little bit the buttonbar:


Also, i’ve implemented contextual buttonbar configuration, allowing to change button’s labels for every menu/screen. For instance i used this with the “LEARN” button, so when you are on Bank/Preset screens you will see “FAVS” instead of “LEARN”.


Regarding the more philosophical discussion, i’m not convinced at all of this “patch”, but as it’s un-intrusive, i’ve not problem with merging on master. I’m pretty sure that it will improve encoderless UX.

And of course, we could think about the possibility of configuring the buttons from the webconf if enough people find useful the feature … in fact, this is almost done by simply reassigning the 4 buttons to the extra switches (4,5,6,7) instead of the primary ones (0,1,2,3).



Ahhhh! BTW, i’ve fixed the touch-back area on the topbar! @wyleu, i now you will love this tiny fix …



It improves a little bit when using transparent-background for text labels:




OK @guys! It’s on master now!
Simply update and check “enable touch widgets” from webconf-> Interface -> UI Options.



For me, tous looks vert nice… and sure, the transparence for Labelle improvise it more than " a little bit"…
Without transparency, the median part of the parameter’s range was hidden… that’such better with transparency…

Works for me!

WOW! This is really something! But please, please, please, add Up/Down too, please.

1 Like

I’d have to agree with @sailort. Touch-and-drag scrolling is great for synth parameters, but not so great for menu scrolling. We need something more precise than that.

Should we just put them alongside the others in the “touchbar”?

Another idea: also decrease scrolling sensitivity in menus? It would take longer to get to the bottom of the list, but it would be way more precise.

Having trouble running this on an hdmi, which I would control from a mouse to access touch widgets. It’s killed the display stone dead on start up.

This was after switching repo to this branch and back from gui interface.

Working on zynthian-bigtouch.local ( 7" touchscreen)

I would suggest border of the buttons are not in dark grey but hilighted along with the button seperators.

Simply because when viewed off axis the touchscreen buttons become difficult to distinguish.


this is a 3.5" touch screen …

Is there any attempt for Up/Down for selector ongoing? That would be huge improvement for encoderless zynth with 3.5" screens. Please.

Loving having these buttons on my Screen. Thanks for everything.


@Jtunes, have you tried the menus in step sequencer (particularly the feature/stepseq branch rather than master)? These use a different method of scrolling menus with different dynamics. It would be interesting to see whether this gives better, worse or same behaviour to that you experience with the default scroll mechanism.

I prefer the idea of using pop-up control like menus which means there is insignificant impact on screen space and content can be context specific. The menus I added to step sequencer are accessed by touching the topbar, present a BACK button in the top bar and context sensitive options within the menu.

Another feature I developed for step sequencer is a parameter editor which is displayed within the topbar, with up, down, assert and cancel buttons and a display of the parameter and value. This allows adjustment of values with touch / mouse again without impacting screen space significantly.