Questions specific to gestures..."back"

undrwater

@kugiigi said:

The best we can do is probably to design the standard toolkit to make it easier to trigger.

That's kind of the idea I was considering. I see now that you have something implemented, so I'll check that out.

I'm certainly aware there is no "global back", and that it gets complex to code the correct behavior.

Thanks for your response!

ChromiumOS-Guy

@undrwater unfortunely we're kind of like IOS in this regard.

kugiigi

@projectmoon There's a setting for that inside Ambot however it only works in unconfined apps.
Not though that there apps that use the affected components in unusual ways so the hint may show in weird places e.g. Music app, the hint shows above the currently playing bar

In regards to the global back action, we can implement it in the toolkit, you just have the back button trigger with the back button but we can't really enfore it everywhere else so it will be kind of pointless if it only works in certain apps

undrwater

@MrT10001

Imagine you only had one hand to work with. It's not beyond the realm of possibilities.

haagch

@kugiigi Mouse Button 8 is usually mapped to Back, Mouse Button 9 to Forward. Here on desktop plasma wayland, in a quick test Firefox, Thunderbird, Dolphin and Kate do something with it. I wouldn't know if emulating those events would be a good idea, or if encouraging apps to respect it would set a bad precedent that everyone will regret in the future though.

I also tried connecting a usb mouse to Ubuntu Touch. It looks like those mouse buttons are not mapped at all, at least none of the apps react to it, including firefox(xmir)

kugiigi

@haagch There's a separate back button but I guess the mouse back button is better supported in desktop apps.
And yes, it's currently not working in UT.

MrT10001

@undrwater said:

Imagine you only had one hand to work with. It's not beyond the realm of possibilities.

That is one scenario, but with a big screen device you would struggle to get across the screen in some scenarios one handed too.

CiberSheep

@undrwater the thing is Ubuntu Touch is a left, top OS.
It would ideal is developers follow the Human Interface Guidelines and stop pushing bottom controls into apps.
And again, there is no «global back» concept because we have the app spread to switch from app to app. And the launcher to launch apps. Of course there's an in-app back, end it is on the top left corner.

grenudi

@haagch said:

I wouldn't know if emulating those events would be a good idea, or if encouraging apps to respect it would set a bad precedent that everyone will regret in the future though.

Let me help you with that. Here is how others comprehanded the problem:

the comment from haagch actually makes it worse for Ubuntu Touch's case — not just gestures, but even Mouse Button 8 (the universally understood hardware "Back" button) doesn't work. That's a regression compared to even basic desktop Linux setups.

Everyone else already solved this

Android has had a system-level back gesture since Android 10 (2019), with the edge-swipe-in model, enforced across all apps

iOS has had the swipe-from-left-edge back gesture since iOS 7 (2013) — over a decade of use

KDE Plasma Mobile had navigation gestures in Plasma 5, and for Plasma 6 Devin Lin rewrote the entire task switcher, including navigation gestures, as a KWin effect for better performance

Phosh has had its own back/navigation gesture model as part of the mobile shell

SailfishOS has had edge-swipe navigation as a core UX pillar since launch

The Wayland fragmentation problem

This is where the real structural issue lies. Touchscreen gestures are not interpreted by libinput — any touch point is passed to the caller, and interpretation of gestures is up to the caller or the Wayland client, because libinput has no knowledge of window coordinates or UI context. This means there is no system-level back gesture protocol in Wayland — every compositor/shell has to reinvent it independently.

The Wayland pointer gestures protocol currently provides a global interface for touchpad gestures (swipe, pinch, hold) but this is at the compositor/pointer level, not an app-level "back" semantic.

KDE is actively trying to improve this — Natalie Clarius and another contributor received an NLnet grant to improve gesture support in Plasma, with one working on stroke gesture support in KWin and the other on making multi-touch gestures customizable — but this is KDE-specific, not a cross-desktop standard.

The Mouse Button 8 case makes it embarrassing

The haagch comment highlights something simpler than gestures: BTN_BACK / Mouse Button 8 is a decades-old hardware standard that Firefox, Dolphin, Thunderbird and Kate all already respond to on desktop Plasma/Wayland. Yet on Ubuntu Touch, none of the apps react to it, including Firefox running via XMir. That's a basic input event that requires zero new protocol design — it just needs to be plumbed through and respected.

The bottom line

The debate about whether to have a global back gesture is effectively settled by the entire rest of the industry. The remaining Linux/Ubuntu Touch question is purely implementation and coordination — specifically:

Should it be a Wayland protocol-level semantic (compositor tells apps "back was triggered")?

Or should compositors translate it to a keyboard shortcut (like Alt+Left) that apps already handle?

And in the meantime, why isn't BTN_BACK even being forwarded?

The precedent from Android, iOS, KDE Mobile, Phosh, and Sailfish isn't just strong — it's essentially unanimous. There's nothing left to debate philosophically; it's an execution problem.

grenudi

@undrwater @kugiigi @mrt10001
@chromiumos-guy

let me llm it for you (@oldbutndy llm usefulness needless example)

A few things stand out from the full thread worth noting:

CiberSheep's argument is self-defeating

"Ubuntu Touch is a left, top OS. It would be ideal if developers follow the Human Interface Guidelines and stop pushing bottom controls into apps."

This is circular reasoning. The entire reason a global back gesture matters is precisely because you can't enforce where developers put their back button. Saying "just follow the HIG" is the problem statement, not a solution. Android had the same issue and solved it at the system level exactly so app developers couldn't break navigation.

kugiigi is being honest but defeatist

He built MariKit, has multiple personal experiments, clearly understands the problem — then concludes "it will be kind of pointless if it only works in certain apps." But that's exactly the argument for doing it at the compositor/shell level rather than the toolkit level. The toolkit approach failing doesn't mean the idea fails.

MrT10001's "just use two hands" response

Classic dismissal that undrwater correctly shot back on — accessibility isn't an edge case, it's a design requirement. One-handed use is a real scenario for anyone, not just people with disabilities.

ChromiumOS-Guy comparing UT to iOS

"We're kind of like iOS in this regard"

Except iOS has had the left-edge swipe back gesture since 2013. That comparison actively proves the point rather than defending UT.

The most revealing moment

@kugiigi , who is clearly one of the most technically capable people in the thread, has already shipped working implementations in his own apps. The knowledge and the code exist. What's missing is someone with shell/compositor access deciding to make it a first-class feature — not a toolkit patch, but a proper gesture handled at the Lomiri level before it ever reaches the app.

That's the actual gap.

arubislander

@grenudi OK, Please stop feeding forum posts to your LLM and then posting long sentiment analyses as answers. It pollutes the discussion thread. Consider this your first and only warning.

Here is a place for open discussion, but forcing people to be confronted with AI generated long-winded and bloated responses is an abuse of their time.