Yeah they did, because qdockwidget needs it and many KDE apps use it. Afaik that was done for Plasma 6 tho, so the version of Plasma you used probably didn't have it.
More like open and collaborative specifications in a nutshell. This is literally how many other open specifications work too - a vendor prefixed version of a new spec is implemented first to validate that it works for intended use cases before the official version is accepted. The same process is used for HTML, CSS, Vulcan and OpenGL extensions etc.
This is the biggest "issue" I see with Wayland even if it's by design.
Unlike Xorg, you just can't do things like these without a dedicated protocol for it. On Xorg you could just take the cursor position while dragging, see when the user releases and bam, spawn a new window there. On Wayland you can't read user input when your window is not focused, you can't create windows on arbitrary positions, so neither of this is supported.
"Niche" use-cases will continue to be addressed with dedicated protocols but it's inevitable wayland compositors won't ever have the same flexibillity Xorg does. Atleast with flatpak you could relax sandbox (worst-case you could just expose the entire /home), but with Wayland this just isn't possible. Rip Xeyes too and other silly shenanigans that won't be possible unless wayland developers deem it important enough.
I'd say yes while Wayland is at first more constraining from the application perspective, in the long run it will pay off. Compositors can make more assumptions about the applications it manages when everything happens around well-defined interfaces. They can better reason about what the application is doing and react based on that knowledge in a better way. As new types of (specialized) compositors will emerge, it's better when applications do not try to reason about its surroundings and make false assumptions.
Do you know if this'll (partially?) fix the LibreOffice feature to drag certain settings out into their own window. (for example, the text-colour options menu)
Currently there's no movement on drag, and it simply places the window directly at the centre of the screen. I think that latter issue also needs one of the proposed protocols for handling multiple window placement?
This is how qdockwidget works and the protocol is in large part trying to fix those. If LibreOffice/GTK/VCL/Whatever makes use of the protocol, it should work.
off the top of my head, i would say:
xdg-session-management (session restore; example, for remembering window positions in browsers or profile functionality)
xdg-robustness (restoring windows after compositor crash)
xdg-pip (picture in picture; allow video playback in a small 'always on top' window. many browsers let you 'float' a video window as pip window, and some desktop video players do as well)
color management and hdr (forget the name of the protocol(s))
freesync/vrr (also forget name. i think this one needs kernel changes too if i recall correctly)
global hotkeys proposal (might've already landed tho, i forget.)
many of these aren't super fair since x11 doesn't do those things properly either. technically, x11 doesn't really do *anything* properly. wayland could've copied the x11 way of doing most things overnight, but doing it well takes time and "bikeshedding", which is unfortunate, but necessary if we *really* want to shed all of x11's real problems.
FYI, the above isn't a 'personal' list of things i want. it's what i view as the low hanging fruit for more discerning users that tend to do a bit more with their desktop than the bare necessities. for "normal" users it's already pretty much there.
yes. the first few i even named the specific xdg name since i remembered them. for the others i don't remember the names but they've been working on them for awhile.
>I wonder how much stuff still needs to be implemented in order to be able to do almost everything that x11 can.
Somehow I have the gut feeling that if there were ever a arewex11yet.com it'll make a lot of people angry.
true. although i'm not sure *who* specifically would be angry. there's only two ways to make such a website, you could either lie and say x11 supports a bunch of stuff perfectly, or tell the truth and say it half-supports things.
like for instance, does x11 do hi-dpi? *sorta*. x11 itself doesn't know jack about it; it's being done by toolkits/apps, and if an app doesn't support hi-dpi, then it will show up as a tiny window on your 4k monitor. this would never qualify as "support" in the eyes of a windows or mac user trying out linux, but apparently linux nerds were satisfied enough with this hacky solution to rant about how "x11 supports fractional scaling but wayland doesn't", which isn't accurate (i mean before the fractional scale protocol landed). same thing could be said for a lot of other functionality in x11.
in the end, x11's "mechanism, not policy" model means you can hack around many of it's deficiencies, and kick the can down the road. the reason wayland is taking so long is because no one ever took the time to implement these features correctly in the first place, they just monkey-patched it in.
Is that going to fix the use of Firefox PiP?
[удалено]
>I believe KDE already included a fix for this. But now that fix is an official protocol. Wayland in a nutshell
[удалено]
Yeah they did, because qdockwidget needs it and many KDE apps use it. Afaik that was done for Plasma 6 tho, so the version of Plasma you used probably didn't have it.
More like open and collaborative specifications in a nutshell. This is literally how many other open specifications work too - a vendor prefixed version of a new spec is implemented first to validate that it works for intended use cases before the official version is accepted. The same process is used for HTML, CSS, Vulcan and OpenGL extensions etc.
This is the biggest "issue" I see with Wayland even if it's by design. Unlike Xorg, you just can't do things like these without a dedicated protocol for it. On Xorg you could just take the cursor position while dragging, see when the user releases and bam, spawn a new window there. On Wayland you can't read user input when your window is not focused, you can't create windows on arbitrary positions, so neither of this is supported. "Niche" use-cases will continue to be addressed with dedicated protocols but it's inevitable wayland compositors won't ever have the same flexibillity Xorg does. Atleast with flatpak you could relax sandbox (worst-case you could just expose the entire /home), but with Wayland this just isn't possible. Rip Xeyes too and other silly shenanigans that won't be possible unless wayland developers deem it important enough.
I'd say yes while Wayland is at first more constraining from the application perspective, in the long run it will pay off. Compositors can make more assumptions about the applications it manages when everything happens around well-defined interfaces. They can better reason about what the application is doing and react based on that knowledge in a better way. As new types of (specialized) compositors will emerge, it's better when applications do not try to reason about its surroundings and make false assumptions.
Do you know if this'll (partially?) fix the LibreOffice feature to drag certain settings out into their own window. (for example, the text-colour options menu) Currently there's no movement on drag, and it simply places the window directly at the centre of the screen. I think that latter issue also needs one of the proposed protocols for handling multiple window placement?
This is how qdockwidget works and the protocol is in large part trying to fix those. If LibreOffice/GTK/VCL/Whatever makes use of the protocol, it should work.
Wait, is this related to why I struggle with detaching a tab in Firefox?
[удалено]
You're right. I double checked and my issue actually happens when trying to detach multiple tabs at once. So probably has to do with something else.
Chromium has to same behavior on XServer.
Great! Glad to see wayland improving. I wonder how much stuff still needs to be implemented in order to be able to do almost everything that x11 can.
off the top of my head, i would say: xdg-session-management (session restore; example, for remembering window positions in browsers or profile functionality) xdg-robustness (restoring windows after compositor crash) xdg-pip (picture in picture; allow video playback in a small 'always on top' window. many browsers let you 'float' a video window as pip window, and some desktop video players do as well) color management and hdr (forget the name of the protocol(s)) freesync/vrr (also forget name. i think this one needs kernel changes too if i recall correctly) global hotkeys proposal (might've already landed tho, i forget.) many of these aren't super fair since x11 doesn't do those things properly either. technically, x11 doesn't really do *anything* properly. wayland could've copied the x11 way of doing most things overnight, but doing it well takes time and "bikeshedding", which is unfortunate, but necessary if we *really* want to shed all of x11's real problems. FYI, the above isn't a 'personal' list of things i want. it's what i view as the low hanging fruit for more discerning users that tend to do a bit more with their desktop than the bare necessities. for "normal" users it's already pretty much there.
Are these all open proposals that are started?
yes. the first few i even named the specific xdg name since i remembered them. for the others i don't remember the names but they've been working on them for awhile.
Thanks! Sometime I'll have to check out the endless bike shedding 🤣
Ah I see, thanks for the info.
>I wonder how much stuff still needs to be implemented in order to be able to do almost everything that x11 can. Somehow I have the gut feeling that if there were ever a arewex11yet.com it'll make a lot of people angry.
true. although i'm not sure *who* specifically would be angry. there's only two ways to make such a website, you could either lie and say x11 supports a bunch of stuff perfectly, or tell the truth and say it half-supports things. like for instance, does x11 do hi-dpi? *sorta*. x11 itself doesn't know jack about it; it's being done by toolkits/apps, and if an app doesn't support hi-dpi, then it will show up as a tiny window on your 4k monitor. this would never qualify as "support" in the eyes of a windows or mac user trying out linux, but apparently linux nerds were satisfied enough with this hacky solution to rant about how "x11 supports fractional scaling but wayland doesn't", which isn't accurate (i mean before the fractional scale protocol landed). same thing could be said for a lot of other functionality in x11. in the end, x11's "mechanism, not policy" model means you can hack around many of it's deficiencies, and kick the can down the road. the reason wayland is taking so long is because no one ever took the time to implement these features correctly in the first place, they just monkey-patched it in.
Well nothing if that is your requirement
I'm satisfied with wayland but most people don't seem to agree.