Hi all. I am having issues with touch screen with pull-down menus on a Dell Venue. I can touch the menu bar heading and the menu bar drops down, but the item in the pulldown only hilites when touched, the pulldown doesn’t disappear, and the action doesn’t take place. A regular mouse works just fine. This is with ubuntu gnome. I originally discovered the issue using wxWidgets built against gtk3. After some discussion with them, it became apparent that the issue was really with the underlying gtk3. I copied and built from https://developer.gnome.org/gtk-tutorial/stable/x1577.html which is really intended for gtk2. Lacking anything better, I built it against gtk3, ignored lots of deprecated messages. It showed this issue as well. I’m not sure using code intended for gtk2 is a fair comparison, but I could find no other example code. Also, the touch worked for the menu with this example if built from gtk2, though there are other issues were I to go to wxWidgets with gtk2. Was hoping someone here might have ideas. Thanks.
The errata:
Dell Venue II Pro 7140
ubuntu 20.04
gtk3 version: libgtk-3-0 3.24.20-0ubuntu1
I think there is a general problems with menus/X11 combination. I have reported one issue regarding opening a Menu apparently has a weird effect not expected from"average user" but the issue was dismissed with the argument that this is the way X11 works and we have to live with it
That’s not what Matthias wrote in the issue you opened:
menus do block all input under X11; menus use an override-redirect window, and grab all the input. This is the reason why, for instance, screen savers cannot trigger, or why you cannot take a screenshot, under X11 when an application has a menu open. This is inherent to the windowing system, and cannot be changed or fixed.
the issue you filed deals with an application blocking the main loop; since all GTK applications are single threaded, and the event handling happens in the same thread that does everything else—layout, drawing, application logic—then blocking the loop will have the effect of preventing the menu from closing. This cannot be changed in GTK, because we rely on synchronous operations between toolkit and application logic (for instance, all the event-related signals have the ability to stop the propagation down the signal chain, which cannot be done asynchronously). The solution is to prevent applications from blocking the main loop. The demo you were trying is intentionally blocking because it’s trying to artificially find out the upper bound of the model API.
@ebassi Thank you for clarifying the roots/backgrounds of this issue. I hope that new and modern technologies like Waylang/Gtk4 would overcome these shortcomings and fullfil the expectations of desktop users.
Thanks.
Thanks for the hints. I tried Wayland and the pulldowns worked now. None of the buttons worked though, so it wont work for me. The url is very interesting and may be what I need if I can sift through it. Thanks for that. This is in regard to lb90’s suggestions.
