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