@scottjenson @jeremy_data Fixing some of these stuff will be quite an undertaking and most of them are actually handled by toolkits rather than OSK, but I'm pretty sure that at least @dcz will be eager to discuss 😁

@dos @jeremy_data @dcz That's understandable, why reinvent the wheel? But that's how we got in this mess in the first place. Besides, these toolkits do not work out of the box on mobile, they TOO have to had text handles, long-press, and pop up menus so there MUST be mobile specific code on top of these libraries.

@scottjenson @jeremy_data @dcz Surprisingly, not that much actually - some things had to be fixed as they were poorly tested or bit-rotten, but as far as I'm aware most of the underlying stuff in GTK dates back to GTK3's initial push for touchscreen support around the time when laptops with touchscreens started appearing on the market.

I guess libadwaita may be a place for some of this stuff too.

@scottjenson @jeremy_data @dcz You may also be interested in text-input Wayland protocol that lets the OSK and apps communicate with each other: https://wayland.app/protocols/text-input-unstable-v3

There have been lengthy discussions taking place on what is needed for the next versions of the protocol: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/39

@dos @scottjenson @jeremy_data @dcz targeting the underlying wayland input protocols would be great (and hopefully unify the current v2/v3 friction between environments :D ). Wouldn't the zoom/ lens feature require adjustment in the compositor anyway?

There are a few things from the demo which I don't quite understand. The "hard press" for the menu seems to require some level of hardware support?

@pak0st @dos @jeremy_data @dcz We did it with the barometer sensor which was great for testing pressure on the glass. The other approach might be to have the touch screen return the size of the finger on the glass and use a variation of the size to detect a stronger press. Both of these approaches are a bit noisy and would need some careful work to detect a drag-press reliably

@scottjenson @pak0st @dos @jeremy_data @dcz

I suspect my Alldocube iPlay 50 mini doesn't have a barometer sensor.

@scottjenson @dos @jeremy_data Please I beg you, find a way to fix text editing. As someone who never used a touch screen for typing until getting a Librem 5 (yeah I develop the input method, fight me), I hate text editing with a passion already.

@dcz @dos @jeremy_data Happy to. How can I help?

@scottjenson @dos @jeremy_data I think it would be best to modify the GTK toolkit directly.

https://gitlab.gnome.org/GNOME/gtk/

@tbernard is one of the UX designers for GTK and may guide you towards the best path to get this included.

@dcz @scottjenson @dos @jeremy_data we're definitely interested in this from the design team side, we discussed scott's blog post a few weeks back on the design call. my takeaway was there's a number of tricky things here:
- finding a design that can work for hardware without fancy sensors
- how to iterate in a prototype before deciding on a behavior
- there's not that many input experts and the ones i know are super busy with other important stuff at the moment

@dcz @scottjenson @dos @jeremy_data a concrete next step could be finding someone who wants to do some prototyping and then iterating on a design, and keeping the relevant input/toolkit/design people (carlos, @verdre, @alice, @allanday) in the loop.

@tbernard @dcz @dos @jeremy_data @verdre @alice @allanday I'm happy to jump on a call and discuss the various layers to the problem. For example just cleaning up cursor targeting would be useful (and doesn't require fancy sensors)

@scottjenson @dcz @dos @jeremy_data @verdre @alice @allanday That sounds good, I can organize something.