The new gui selector_info class probably needs some adaptation. Also the html help view.
Regards
1 Like
I donât see any problems. They should appear immediately in the main menus, if there were any, right?
Originally, I had to adapt grid settings for some of the basic screen classes - donât know why, maybe the widgets there were not nested, but in the newer ones they are? (Maybe I even âadaptedâ more than really necessary, then?) I got a bit lost. However, it seems to work. These widgets are probably already nested.
1 Like
Oh, right, the help screen needs adaptation! A small fix⌠just cannot find how to limit the height of the widget at the momentâŚ
I donât get the magic of grid_propagate - it works five times and the sixth time it suddenly breaks??
Anyway, I tried all combinations and orders of the function call and now it seems to be working for me, so I committed the changes to the help widget and letâs hope it will keep its height and not expand to the full display height anymore.
I already reviewed and merged to v5touch branch. I made some minor fixes, but most of code is OK! Now awaiting @ribanâs review to merge in vangelis.
Good work, @wanthalf !!
Regards
1 Like
Observations:
- Update does not restart webconf.
- Requires hardware configuration to work - should this be automagically configured when selecting Touch-keypad?
- Font on buttons too wide when font size = 16. Reducing to 14 fixed this but I think the button text should just work and always fit, no matter what the overall font size selection.
- I manually disabled touch navigation. I wonder whether we need separate configurations or whether these could be mutually exclusive?
- Selecting V5 Customisation Profile did not apply this profile until I changed lots of settings then reselected it.
- The main display (inside the touch buttons) is smaller than I would like. It would be advantageous to be able to toggle full screen. Maybe tapping the topbar could do this? (Need to consider touch navigation.)
- Bold/long press of buttons has no effect, e.g. you cannot access html help.
- Does it may any sense having âV5 Touch Keypadâ in the admin menu?
- Canât select a page of controllers in the controler view with touch, e.g. amsynth: Touch âOsc1â - nothing happens.
It is a cool implementation that may help users with larger touchscreens. If a full-screen mode were available it may be nice on a 5" but I feel there is too much screen taken over by buttons to satisfy me. Nice work!
[Edit]
- In powersave, VNC still shows the main screen plus the pulsing OPT button. Not an issue, just a bit odd.
- Waking screen from powersave with mouse, e.g. over VNC does not exit powersave mode.
- Hover over button with mouse highlights button in grey. This can lead to buttons being left highlighted if mouse ponter is left there.
- Errors in log:
Dec 02 10:20:19 zynthian startx[1749]: Exception in Tkinter callback
Dec 02 10:20:19 zynthian startx[1749]: Traceback (most recent call last):
Dec 02 10:20:19 zynthian startx[1749]: File "/usr/lib/python3.11/tkinter/__ini
t__.py", line 1948, in __call__
Dec 02 10:20:19 zynthian startx[1749]: return self.func(*args)
Dec 02 10:20:19 zynthian startx[1749]: ^^^^^^^^^^^^^^^^
Dec 02 10:20:19 zynthian startx[1749]: File "/zynthian/zynthian-ui/zyngui/zynt
hian_gui_control.py", line 769, in cb_listbox_release
Dec 02 10:20:19 zynthian startx[1749]: rdts = now - self.last_release
Dec 02 10:20:19 zynthian startx[1749]: ^^^^^^^^^^^^^^^^^
Dec 02 10:20:19 zynthian startx[1749]: AttributeError: 'zynthian_gui_control' ob
ject has no attribute 'last_release'
- After a reboot I had problem with not starting and error in log about routing but suspect that is a hotplug issue.
1 Like
Touch buttons and knobs would be nice with this kind of displays:
Left side touch keys, middle the normal screen, right the knobs.
No my lord!! If you choose a âtoo bigâ font size, everything will be wrong. Thatâs true for all zynthian-ui, not just touch keypad.
In the current state, adjusting the fontsize by hand is always required.
What we could do is add an âautoâ setting for the font size, and leave config code to do some heuristics to determine a good font size.
1 Like
Itâs fixed. It was me refactoring some repeated local variables.
1 Like
BTW, v5touch is merged in vangelis. You can forget the v5touch branch forever.
Enjoy!
2 Likes
It seems daft to offer font size then tell users not to use it! My point here is that the touch buttons are a known, fixe size so it makes sense to have their text of a known, fixed, optimal size.
It depends strongly of the display size. For small displays, you have a small range to select a âgoodâ font size. For bigger displays, you would have a wider range, so it has more sense to have the possibility to choose.
Anyway, there is a lot of room to improve things. For instance, we could have 3 options:
- small
- medium
- large
and leave the config code to choose the exact font size value, using the user preference as part of the heuristics.
Regards,
1 Like
I put a lot of work into making touch navigation work on zynthian (without real or virtual buttons). The more I use the onscreen buttons the more I see the advantage of a hybrid where buttons can be popped up on demand but that the performance views can go full-screen. The previous (and still implemented and used by touch navigation) onscreen buttons, topbar, controls, etc. can all be shown and hidden. These new onscreen buttons should use the same mechanism to allow them to be shown and hidden on demand. We could then add workflows that allow the buttons to be displayed or hidden as required. The following screens benefit from full-screen:
- Mixer
- Zynpad
- Arranger
- Pattern Editor
- X-Y
At least, user should be able to customise font size to own liking. I use size 16 and am happy with it on the good 1280x800 screen.
Zynthian is not a Mac, so there shall not be patronising as if it were one.
I agree, existing touch implementation works and buttons are only necessary for new users that still learn zynthian ui. Therefore, I also think that these buttons should be visible only when user asks for them and automatically hidden after some period of inactivity.
Implementing a âfluidâ hide/show is far from trivial and i fear without this itâs going to be too sharp.
Anyway, itâs doable. The dirty âsecretsâ to make it work are hidden in the pattern editor zooming functionality 
Regards
We would also need a proposal for this
And yet we have already done it! 
I added the ability to show and hide elements (topbar, button bar, controls, etc.) and added the main view automatic resizing. Unfortuanately, this latest development has not hooked into that. If it does then it should just work.
1 Like
Iâm pretty sure @wanthalf would have a think about it
1 Like
Thanks everyone for proper testing and discussion.
I have thought about it, but I am not sure. It think it would be better to change the wiring configuration as a whole, somehow. Or, maybe, all switches could be just configured to pin â-1â by default, unless explicitly defined otherwise? Or with other words: make switches work even if they have no pin assigned. If a switch does not need to be physically present in the form of a GPIO input just to be used, there is no reason to limit its existence to its pin being configured.
The other requirement would be to activate the V5 configuration somehow, which is currently only automatically done when V5 is detected or selected as wiring profile.
I donât see any reason. I use both and I like it. The buttons are an alternative to physical buttons on the official V5, not to the touch navigation.
- The touch navigation is the most important basic feature. It allows people to make a zynthian just using a touchscreen and nothing else. Perfect for beginners, testing, experiments or users, who just learn to control everything using gestures.
- Physical encoders and buttons are useful for professional use, probably especially on the stage. But they require you to do some tinkering, if you are in the DIY track. And the buttons are very difficult to implement in a way both practical and estetically pleasing (at least from my perspective).
- People without established habits and workflows (beginners, occasional users, etc.) may just like to use all the methods as they just feel at the very moment or for different purposes: encoders for scrolling and changing values, touch navigation for quick changes on the screen and (touch) buttons for quick access to other screens and menus (that would require several touches using just the navigation) or to trigger custom functions (switching subsnapshots, etc.)
You mean on a 5" screen? There is absolutely no point using this with a 5 inch screen or smaller. The goal is to utilize a 7" display (or larger), where you just reserve the basic 5 inches for the common screen and use the additional area for the buttons that you do not want to implement as physical ones.
Actually, on a 7" screen, the basic zynthian screen seems needlessly huge - at least to me. The widgets are bigger than I need. I guess people might prefer to have more columns in the mixer instead of having the mixer widgets larger, and so on⌠but that is a subject for another discussion in a different place.
Strange. It just works for me all the time since you adviced me how to implement things correctly. Something else must be wrong.
Good question. While I suppose people either will have the touch buttons active all the time or not at all, I thought a simple way to turn them temporarily off may sometimes come handy, though. I can imagine someone will use them at home, but then, coming to the stage, prefers the fullscreen mode with bigger widgets and has no computer at hand to turn it off in the webconf. Or the other way around. Whatever.
The power safe mode is something I have already questioned here somewhere at the beginning and did not decide about the best solution. Actually, I have not really seen it since - my display just turns off completely.
The VNC is also another source of unresolved issues as you mention. I donât really know how it behaves and why, but when trying to play with the button widget configuration, I either managed to solve the âVNC issueâ and âdestroyâ the current look/behaviour, or the other way around. If we can expect people to actually use this via VNC, it could be worth more experiments.