Ah, you’ve got me here. Turns out all this time in X11, both Firefox and Slack windows were being restored and placed with the same dimensions as the tiled state, but not actually snapped into the custom or quick tiles. With 0% padding, it’s imperceptable to being tiled.
It’s a desirable outcome if a “floating” window size isn’t necessary for windows like pop-out Slack channels in narrow tiles, which I’ll want to persist for weeks/months across reboots. I would need a script to automate Window Rules if I were to go that route, based on how often the tiled windows are swapped out.
Wayland currently cannot do this (outside of KDE apps?).
Yes, these are two different but related concepts.
If a multi-window application is targeting Wayland, one would assume this kind of scenario would be anticipated and easily avoided.
A majority of applications using this kind of positioning will attempt to fake window restore themselves instead of using the appropriate mechanism.
However, I think that the zones approach is still a good compromise between global coordinates and no coordinates.
Maybe an option would be to only enable it on request, so that the user knows they have activated legacy window placement and might experience broken behavior.
Potentially even as a per-app permission instead of a global setting so users have an easier way to pinpoint the cause of misbehavior
This has happened before? From what I read in the big MR, this concern is only theoretical, and mistrusting of app developers. If the protocols stay stalled over what-ifs, I can see app developers being forced to find hacky workarounds for lack of proper support.
If global coordinates weren’t shot down from the start, this feature might have shipped years ago.
It’s been rehashed ad infinitum but why would an app target Wayland when the others (Mac/Win/X11) all support that basic concept? Wayland is unnecessarily an outlier.
They are doing it now (using window positioning to “restore” them), it just doesn’t work when running on Wayland.
I have seen claims by application developers that their restore functionality is not working properly because they can’t position windows, when in fact they wouldn’t need to do that at all when using the respective session management mechanism.
So either their claims are clumsily written or they have so far not made use of the proper support.
How confident are we that it is the former?
Global coordinates are obviously not a good idea but a kind of virtual/local coordinate system like proposed by the zones protocol does sound reasonable to me.
What I found strange is that there appears to be very little engagement with the zones protocol by application developers who claim to need it.
If you look at the merge request it appears that only the protocol author and one other developer (who implemented it in SDL) have actually evaluated it for their use case.
Given how widespread the claims about its importance are, one would expect dozens of comments from application developers who have verified it works for them as well.
I’ve come to understand that’s the usual behavior under X11 though? If Wayland as the compositor is the final word to prevent misbehaving apps, is it not able to catch this condition and handle it properly?
I imagine app developers have more important things to do than to track these mega-MRs, especially how it’s dragged out this long. How much engagement on the former closed iterations were from those parties?
It’s only been a week since the KDE announcement for X11 EOL, I imagine the discussion will pick up in earnest soon.
Yes, because it lacks a more sophisticated way.
For Wayland there is a better way, as it allows the window manager to save all of its window related state.
The protocol for this has reached a new-final state a couple of months ago and can be activated in KWin, Mutter and others for testing apps against them.
Chomium and Firefox have done client side implementations.
So it is strange that apps which have claimed to need window restore have not done so as well.
Maybe with a lot of effort. This is the situation for X11 window managers which needed to implement and maintain lots of workarounds for misbehaving clients.
The idea for Wayland is to let app and compositor collaborate instead of compositor guessing and potentially guessing wrongly.
Apps implementing this properly would have increased compostor developers’s trust in app developers ability to do the right thing.
I’ve seen claims that this type of functionality is essential for some apps.
Something that is essential is usually treated as something important.
Having basically only two app developers engaged with the protocol MR makes it look as if it is not quite as important as some people make it out to be.
Probably even less.
Makes it less worthwhile for others to provide review or compositor side implementation.
Yes, maybe increasing door-close-panic will help getting the attention of multi-window app developers.
One would have assumed that they would like the apps to work as soon as possible.
Developers of other apps have started working on Wayland support many years ago, got protocols and APIs established that they needed.
I concern I have right now with canning x11 so early, is that it will heat up division and friction between developers like a certain dev who I won’t mention by name who is a complete nut.
Maybe things might turn out better than I think it will, but I’m rather surprised things have been civilized with the discussions I’ve seen both here and /r/kde.
Thanks reply. I glad to lissten that.
I saw Krita developer team is discussion of Wayland workfrow before.
If KDE Wayland plan is good for artists too is very good.
I like Linux and KDE plasma system. I want using it in the future. Thanks KDE Developers.
I use X11 now, But if come good point day on Wayland, I go to Wayland.
And thanks you reply to me again. I remembed you. I want to be kind developer like you.
For application side I found this information for Chromium
Both Chromium and Chrome on my system have the chrome://flags/#wayland-session-management option, Edge does not.
Haven’t checked if any of my Electron based apps understand the associated command line switch.
It seems I remembered incorrectly about Firefox having support as well.
Their ticket for this is still open without any patch.
For Qt the environment variable to set is
QT_WAYLAND_ENABLE_XX_SESSION_MANAGER = 1
and apparently landed in Qt 6.10.
Haven’t checked GTK, however since Mutter has support for this as well there is a high chance this is also supported in their primary toolkit.
I will note that @breakingspell referred to x11vnc, whereas all that krfb is currently offering is more like x0vncserver. As such, there is nothing happening there that looks to be in the direction of enabling fully headless sessions; they have a tool for creating virtual monitors, but you cannot launch a Plasma session on one (and even those do not have input support anyway).
I have reported the above, and earlier I reported against kwin_wayland/plasma-session to see if it could be started with kwin using its virtual backend (as a step towards a VNC implementation at the appropriate level in the stack, which krfb isn’t for a headless use case). Both have lain silent for some time. (All that has really told me though is that I may have been looking in the wrong direction for where I imagined the necessary parts might come from.)
I know that this use case is not entirely off KDE’s radar: they do reference headless RDP, if not VNC, on the Known Significant Issues page no less; RDP/VNC support “from startup” is something “we want” for plasma-login-manager, although whether that includes headless is not indicated and I see no activity in the repo towards this “want” anyway.
I’m also dimly aware that there are things progressing among portals, pipewire and wayland protocols that may come together eventually, but the pace seems glacial and again I’m not sure whether the headless case will even be included.
As a workaround I experimented with launching plasma-wayland inside another compositor that does support VNC (e.g. cage + wayvnc ) but there were severe rendering bugs ca. plasma-6.4 and as of 6.5 it doesn’t launch at all.
Note I don’t expect a free lunch. This use case is not widely held, as passionate about it as I and its other seekers may be, and is clearly a significantly more complex proposition than plain screen-sharing, so KDE devs may legitimately dismiss it altogether. But it is frustrating to see so many tantalising pieces of the puzzle littered around the environment and think it might not take that much to bring them together if the right people took an interest.
Most of all it’s exhausting how many times I’ve raised this subject and had to reiterate an umpteenth time to a (well-meaning) reply-person that screen-sharing is not what I’m talking about.
That’s encouraging to hear, Nate. (I would prefer to be hearing it wrt VNC personally as I’ve always found it the more robust and interoperable of the two protocols, but if RDP is where the action is, you won’t see me complaining.)
The chicken-and-egg of it is hard to imagine (for me). A systemwide RDP server that integrates with plasma-login-manager? As far as I’ve seen there are no sketches of the architectural approach written in public as yet - if I’ve missed them, please point them out.
Contrast with xrdp where there is frenetic throwing of spaghetti at the wall right now, which looks promising for getting something working quickly but seems a bit convoluted/messy in current form.
I think you are misunderstood what Nate meant. Both headless VNC and RDP will be supported eventually. The missing link is the login manager/auto login and not the protocol. KDE already has support for both through KRDP and KRFB (this is for VNC)
I mean, I can only go on what’s written and one was mentioned here and one not. I took Nate’s comment to be alluding to what work may actually be underway (that cannot be publicly seen anywhere yet, that I know of). That is different from public statements of “Yep we want this to happen” which as you say do mention both protocols.
I don’t think it’s possible to entirely set aside the question of protocol because krdp and krfb are after all distinct projects while both living under the KDE brand, and the work to make them operate on what is a quite different level* than they currently do will be a workload shared between plasma-login-manager and each of those distinct teams. No?
*This is just my halfbaked comprehension but the current apps are launched (auto if desired) from within the Plasma session, so to have one of them (in conjunction with plasma-login-manager) be responsible for launching the session seems like a whole different proposition. That’s what I meant by chicken-and-egg. If it is not as big of a challenge as all that, I wish I understood better, but how it is supposed to work is not yet revealed in public, as far as I know.
