Hi @steveb!
It seems that it’s not perfect yet:
Thanks!
I would prefer we design the interface to align with touch / mouse workflows rather than just add the four buttons which does not deal with the four rotary encoders. An example of workflow based design is the mixer I am working on which allows direct control of the gain, balance and mute of the selected channel and change of selection using encoders / switches whilst allowing direct control of any channel’s gain and mute with touch / mouse, having a pop-up for balance. Each interface is then optimised for the user workflow based on available input method. (I do similar in the step sequencer.) I am worried that precious screen may be occupied by buttons that may not even be relevant to that screen. Also, there may already be a touch / mouse workflow on some screens which may make the buttons redundant. I also worry that we may need to modify code to support the buttons which is yet another overhead to code maintenance. Sorry for sounding negative but it is worth sharing concerns alongside compliments 
.
If we do have buttons, maybe they could be combined with the top bar somehow to reduce screen usage or only appear when relevant.
1 Like
To be clear, the use case for these buttons is for minimal zynthians with no encoders or switches. The buttons will only appear when “Enable Touch Widgets” is checked in the web-ui, and I don’t think it would be appropriate to ever make that enabled by default.
For minimal zynthians I think its justifiable for there to always have buttons present, as they are the virtual equivalent of switches. And having them at the bottom makes sense for a touch interface so your hand isn’t covering screen content to get to them (like the main action buttons on a phone).
The touchscreen interface already has alternatives to the encoders, so its only the buttons we’re missing. The money saved on encoders and IO board can be put into a bigger screen, which makes the loss of screen real-estate less of a concern.
One reactive UI future enhancement which would be nice is changing the labels and hiding the buttons based on the screen context, but that can be done later.
I still haven’t figured out how to get the buttons to claim the height of their parent, I’ve tried a bunch of grid and pack tweaks 
It’s required in pure touch world’s like the 3.5" screen community, because you can get into logical traps like no back button ( the title bar trick) in long layer names.
The zynth & yeti mic combo needs something like this for the disinterested operator… ("Stephanie, can you start and stop the recorder for this next peel . . ? ")
There is a great rate of progress at the moment and we have a lot of new GUI interface options and it’s important that we don’t loose any basic functionality, and provide as standardized a response as we can. So that the disinterested operator feels at home with the tools we offer.
I agree about finger shadowing, we should consider that so perhaps we could consider that being an available 4 function selection opportunity.
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 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).
Regards,
4 Likes
Ahhhh! BTW, i’ve fixed the touch-back area on the topbar! @wyleu, i now you will love this tiny fix …
Regards,
3 Likes
It improves a little bit when using transparent-background for text labels:
Regards,
4 Likes
OK @guys! It’s on master now!
Simply update and check “enable touch widgets” from webconf-> Interface -> UI Options.
Enjoy!
2 Likes
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.