One day?

Some important notes:

1. This is not meant to replace back navigation in app just augment it
2. It's important to have a consistent way to go back on phones ( see android back button and ios back gesture + windows mobile before it died)
3. On android the app is minimized when it can't go back anymore
   • Could be done without a spec (using mouse back em), but then it wouldn't know when to minimize
4. when back is pressed it sends a mouse back click to the app it. then queries if it can go back though a small spec
5. If the app hasn't implemented the spec the back button could either always minimize it or always emulate the back button
6. Should probably be done though dbus but could also work in wayland
7. it'd definitely have to be long term because apps would now need to have back actions determined

Just to clear up my point
On the subject of why it's important:
Generally phones have a lot less real estate to show information, so that means it's likely that an app that is optimized for touch will have multiple views
be it hamburger menu/bottom nav bar or something else.
And that's why you frequently need to go back from the view to the main screen for example
And because every app places back button in a different spot/doesn't have any
it becomes a chore
that's why a universal back button is so important (and present in iOS/android/winPhone)

In Android, there's now by default no back button, but a gesture.
On iOS, navigating back is also swipe-based AFAIK.
I don't see why Plasma Mobile would need a back button. Moreover, I still believe the consensus was that the bottom panel will eventually go away entirely, as long as it doesn't break VM testing.

In T13815#243856, @IlyaBizyaev wrote:

In Android, there's now by default no back button, but a gesture.

While there is no button for it, the gesture triggers the exact same functionality, which still provides its usefulness. We aren't necessarily pushing for a literal back button if we do gestures, but for polishing up a "back action" that can be used by gestures and buttons alike.

On iOS, navigating back is also swipe-based AFAIK.

On iOS, in a majority of the time, the back action is a button in the top left, which can be hard to reach. There may be left side gestures now (I haven't used recent iOS devices), but adding a back action does not necessarily mean we need to remove these sorts of gestures in kirigami.

I don't see why Plasma Mobile would need a back button. Moreover, I still believe the consensus was that the bottom panel will eventually go away entirely, as long as it doesn't break VM testing.

Not necessarily a back button, but having polished back actions would be very nice, as in every app you would have a predictable way to go back in an action.

In Android, there's now by default no back button, but a gesture.

I don't see why Plasma Mobile would need a back button. Moreover, I still believe the consensus was that the bottom panel will eventually go away entirely, as long as it doesn't break VM testing.

Button navigation is an option that is not only available, but also mandatory for OEMs to keep alongside the gestures.

It's also important to note that gestures aren't overly accessible, so it's necessity for some (and preferred by many, myself included).

Still if back button gets implemented it should be trivial to implement back gesture and vice versa. (though I don't believe such convenience should be restricted only to those who like gesture navigation)

On Android, isn't the global back button a hardware thing? Also I'm not sure there's a global back button in iOS.

With respect to gestures, I see them as akin to context menus: invisible accelerators for experts, but never suitable for being the only way to accomplish a task.

In T13815#243929, @ngraham wrote:

On Android, isn't the global back button a hardware thing?

Uh, no? Actually, it's a software button in all modern smartphones.

Also I'm not sure there's a global back button in iOS.

Quite sure there's an option to turn it on. Like, a weird floating button.

I strongly, strongly agree to a server-side back option that can be mapped to a button in the panel, a button, or else

My android phone has a hardware back button in the bottom-right corner of the device, below the screen. Almost every other Android phone I've ever seen has the same thing. Is that a thing that nobody does anymore?

iOS has a global "go home" feature, but that's not a back button per se.

Anyway I'll stop derailing the conversation. I agree that an SSD global back button would be a good idea in PlaMo.

In T13815#243933, @ngraham wrote:

My android phone has a hardware back button in the bottom-right corner of the device, below the screen. Almost every other Android phone I've ever seen has the same thing. Is that a thing that nobody does anymore?

Newer phones have the option between a software bottom panel (with back, home, multitask) and full gestures. Gestures can kinda depend on the OEM. At least for oneplus, swiping in from the left of the screen is the same as the back button.

EDIT: likely the better option for keeping "back" on plamo with gestures would be an implementation like the google pixel

In T13815#243933, @ngraham wrote:

My android phone has a hardware back button in the bottom-right corner of the device, below the screen. Almost every other Android phone I've ever seen has the same thing. Is that a thing that nobody does anymore?

Yeah, only the very cheap ones have it nowadays. We are now in the era of giant screens, there's no space for an entire row of hardware buttons.

Some UX things we discussed:

• Tab bars and elements like SwipeNavigator shouldn't have a back action, as we would need to keep track of the history of what the user pressed, and the user may not even know what it is
• Drawers, Dialogs, Modals, page stacks and page layers should have the back actions specified already
• Certain apps like angelfish can specify custom back behaviour (ex. navigating back a webpage)
• The last back action should minimize the app, not close it (on android, it closes)

Some notes on implementation:

It should kind of take on the form of how key presses are handled in QML, where a keypress starts the child component, and the child can decide a behaviour, and whether or not to "accept" the key press. If it chooses not to "accept", the keypress moves on to its parent.

Alright some notes from discussions:
There are 2 ways we can approach this: generic (sending mouse back events) and powerful (have a dedicated API for it)
There are pros and cons to each method
Generic:

• Pros: simple, doesn't require anything from app developers
• Cons: not extensible, won't work consistently with different apps, could lead to a poor experience nullifying the point

Powerful(API):

• Pros: Extensible, reliable, consistent
• Cons: Requires an implementation from developers (although gives users a good experience), not all apps will be supported

Looking at the pros and cons it's pretty clear that an API is a better long term solution. Which means that we have to figure out which method should we use

1. A D-Bus api. Would need a way to know which window requests should be sent to. Here's a prototype
2. A wayland protocol. Would require digging in Kwin/Plasma

I'd like to hear from Kwin folks if a wayland protocol is a good idea or should we use D-Bus

Is there a way to implement an "emulation" for applications that don't explicit support said back functionality?

Also, when it's mentioned that older applications would need support, is this like supporting GNOME and/or Java-centric applications or applications just needing to update their sources to support said changes?

see generic point

Yeah, only the very cheap ones have it nowadays. We are now in the era of giant screens, there's no space for an entire row of hardware buttons.

@niccolove, many devices nowadays come with a remappable hardware button. Anecdotally, I've seen threads on Reddit discussing how to convert this into a back button.

I did once ask whether this could be implemented at the Qt level (which, in retrospect, doesn't necessarily make much sense). Regardless, if of use, a respondent had some interesting insight:

Interesting topic.

I've worked on two "e-book with embedded interactive widgets"-like applications in the (distant) past.

The first one was initially a desktop application but quite "web-influenced" and "back" functionality was built in from the start. We did it by pretty much encapsulating all the app state of any significance in a URL pointing to a .qml file with all the relevant state in URL parameters. The app had a notion of "history" as a list of recent URLs visited and key transitions between pages or in-page view parameters would also be captured to the history list and when a "back" was received it was just a matter of loading the last captured URL (and ensuring URL parameters were set appropriately). Worked really well (and when we eventually did build an Android version, wiring the device "back" up to do the same as the app's own back button was a trivial no-brainer).

However then there was another kinda-similar application which was initially only envisaged as an iOS thing, and the "back" requirement was dropped because the folks speccing it didn't seem to think "back" was an "iOS thing" or something. Most of the application state just ended up with a messy set of QML properties in it's top-level "main.qml" file. It worked well enough as an e-book (there was always page forward or back buttons or the option to close a page's "pop-up") but then eventually an Android version was done and it became painfully apparent that "device back" needed to do something useful. I think it was wired up to "go back one page" as the least-bad default... but it never quite felt right. For example, if the app's "page 6" had a button to "go back to page 5", and you used that to go back to page 5... then immediately after that you'd actually expect hitting the "device back" to take you back to page 6. But it'd take you to page 4. Fixing that sort of thing would have needed sorting out which state needed to be stashable/reloadable from a "history" list... but noone cared enough about Android to fix it. (If we'd used the URL+parameters-based app state approach from the start it'd have been a lot easier).

Anyway, it's not obvious to me how Qt/QML could completely take-over this sort of thing (unless serializing a bunch of state), and I think it's a lot to do with designing applications such that app state history can be captured succinctly without serializing everything. I could imagine some helpers though... For example Loader::setSource is almost there, but it'd be even nicer if optional properties argument could simply be parsed from the URL parameters. For example: I could imagine some annotation on QML properties which are eligible for "history"... QQuickView::sourceAndState() might return "book.qml?page=5" if the property int page was flagged for state capture and then QQuickView::setSourceAndState("book.qml?page=5") could return to that state. It's quite possible to design that sort of thing into the app (into the environment hosting your QML) with what's there already in Qt though (at least if you think about such things early enough, before the app state has passed the "big ball of mud" event horizon).

I presume this would necessitate a rewrite for participating applications, in some form? If so, parity with AOSP and i(Pad)OS might be more feasible than expected, for Apple's devices' back support is very much existent solely per-application, whereas a great many Android applications don't bother to implement the functionality whatsoever. My point is that most users expect this functionality to be absent from non-participating applications.

I didn't know whether this would be better here or at https://invent.kde.org/teams/plasma-mobile/issues/-/issues/52, so apologies if it's misplaced.