222
After 6 Years, One of Wayland’s Most Annoying Problems is Finally Getting Fixed (itsfoss.com)
submitted 5 months ago by to c/linux@programming.dev
34 comments fedilink hide all child comments
 

There is a new merge on the Wayland GitLab repo. This new merge (of an old pull request) adds xdg-session-management protocol to Wayland. This is a big development and certainly a feature Linux users will enjoy.

As per the brief message in merge request:

For a variety of cases it's desirable to have a method for negotiating the restoration of previously-used states for a client's windows. This helps for e.g., a compositor/client crashing (definitely not due to bugs) or a backgrounded client deciding to temporarily destroy its surfaces in order to conserve resources.

This protocol adds a method for managing such negotiation and is loosely based on the Enlightenment "session recovery" protocol which has been implemented and functional for roughly two years.

In simpler words, session recovery is finally coming to Wayland.

you are viewing a single comment's thread
view the rest of the comments
[–] 8 points 5 months ago* (4 children)

Yeah, it's inconsistent. KDE / QT apps should reliably restore to the right desktop / activity and position. But non-KDE apps like GTK & Electron apps are not consistently restored depending on the app. Instead it depends on work arounds on Wayland and apps can still erroneously open on the current screen / desktop instead. This can be still be managed with Kwin with more workarounds - for example specific rules can be applied in Kwin for really problematic apps if users want - but its faffy.

So this is definitely a welcome change to wayland.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 5 months ago (3 children)

    I am not sure this is true, or at least, if it is it wasn't when I saved my session, because Konsole and Okular don't restore to the correct workspaces.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 5 months ago (2 children)

    I mean many Wayland compositors is kinda like old browsers at the moment. They all implement a common spec and then implement a bunch of their own extensions to get features the spec doesn't allow for. And apps have to be aware of these custom extensions to make use of them. So in the KDE case, I imagine a lot of their apps are aware of KDEs own extensions to Wayland. But it doesn't mean all of them are.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 5 months ago (1 child)

    Surely it'd be absurd for each individual app to need to implement this spec - that defeats the whole point. I can believe it'd be down to Qt or some other library, but as I said, I'm sure that'd apply to those two apps.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 5 months ago

    Yeah, I imagine there's some QT bits for implementing a lot of it, if it detects them being available. Not being massively familiar with QT or how those two apps make use of it, I can't assume they'd be making use of the components that'd implement KDEs custom extensions. So you know shrugs

  • permalink
  • fedilink
  • source
  • parent