7 ms·

What's sad is that after many years Wayland still lacks several things/features that X11 has/allows. Some of them are intentionally not implemented because of s

• laszlokorte 4mo ago
  I know nothing about the detailed technical differences between X11 and Wayland but with Hyprland for me the PIP is working as expected so I assume its not just a Wayland issue but specific to the window manager you are using? Maybe somebody else can explain?
  • tambre 4mo ago
    Gnome has a "Always on Top" toggle for each window. I imagine there's a protocol for an application to set it by default but the OP's window manager might not implement it or there might be an incompatibility.
    • Zardoz84 4mo ago
      Plasma/KDE always had it.
    • blendergeek 4mo ago
      But users do not want to have to toggle that for every PiP video they watch. Its why I am still on X11
      • babypuncher 4mo ago
        I can't speak for Gnome, but KDE makes it pretty easy to create rules that apply automatically to any new window that meets whatever arbitrary criteria you set.
        • kelnos 4mo ago
          That's terrible. That's an "unbreak my software" preference. User's shouldn't have to mess with that; things should just work in ways they expect, out of the box.
          • babypuncher 4mo ago
            I disagree. With how KDE handles this, I'm not at the mercy of the software vendor's whims on what windows stay on top and which ones don't. I have complete control through a standardized interface that can even be automated if I wish. Does it require a little more knowledge on the part of the user? Yes, but it's worth it because with that knowledge comes power.
    • Vinnl 4mo ago
      Gnome has the same problem, that's why this exists: https://extensions.gnome.org/extension/4691/pip-on-top/ https://extensions.gnome.org/extension/4691/pip-on-top/
  • yjftsjthsd-h 4mo ago
    Isn't that usually how it goes? Wayland is a million little optional protocols, which in the abstract is a lovely idea but in practice means which things work depends on which grab-bag of features your compositor supports.
    • gf000 4mo ago
      It's a bit like the web. You have a pretty slow moving list of "protocols" that are well-supported by everyone, and some "new experimental" ones that are only supported by one or two.
  • senfiaj 4mo ago
    As far as I know, there are multiple Wayland implementations. Which is also not good because it creates fragmentation and potential inconsistencies (some subtle differences in behavior, differences in bugs, etc). Maybe Hyprland solves the issue, but I don't want to use this DE just because it solves this particular issue. I have tons of other needs and preferences.
  • moritzruth 4mo ago
    I think in Hyprland it just works because floating windows stay on top by definition.
• aquova 4mo ago
  I can't speak for Chrome, but I can right click a Firefox picture-in-picture window, tell it to remain on top, and it does, no problem. I've been using Plasma Wayland for years now and this has worked for ages
  • blendergeek 4mo ago
    The issue is you have to do that every single time. On X11, they remain on top by default
• csr86 4mo ago
  I fixed this like this: 1. Right click PIP window 2. More Actions -> Configure special window settings 3. Add property -> Layer Force Popup After this it spawned always in middle, I also added property Position Remember, so it spawns where it was previously. I have no idea if this is the best way to fix but worked for me.
• ndiddy 4mo ago
  If you use KDE, you can work around this because of the powerful feature set the window manager has for setting custom window behavior. 1. Right click the PIP window and then click "More Actions-> Special Window Settings". 2. On the window that pops up, click "Add Property", and add "Window title". Change the drop-down from "Unimportant" to "Exact match" (this works on Firefox because the window title is always "Picture-in-Picture", you might have to do something slightly different on Chrome if it does something different). 3. Click "Add Property" again, add "Keep above other windows", change the drop-down to "Force", and change the radio button to "Yes". 4. From now on, all PIP windows will show up on top of other windows. It would definitely be nicer if there was some sort of "always on top" permission that applications could request, but it's not too bad.
  • TiredOfLife 4mo ago
    For Chrome it's "Picture in picture"
  • idoubtit 4mo ago
    Not too bad? A hidden procedure with ten clicks, which the user has to repeat for each web browser. And it may break at any time if the browser changes some details. Or if KDE changes. And it's specific to KDE, with no alternatives in most Wayland WMs. All that for _one_ feature which works out-of-the-box with Xorg, and which Wayland removed for security reasons. From what I've seen, sharing the screen is another common feature which was broken with Wayland and is still painful. I don't think Wayland's security model is very relevant to me since I have faith in Debian for filtering out rogue applications. So I have to reason to drop my smooth UX for a world of "not too bad" workarounds.
    • thesuitonym 4mo ago
      Look, I'm not a Wayland booster, I still prefer X11 most of the time, but this is really the way it should work. Applications should not be allowed to dictate how windows appear. That is the job of the window manager. Chrome's PIP is a stupid workaround for Windows and Mac because they do not have robust window management.
• MegaDeKay 4mo ago
  I have a virtual pinball cab with two (and soon) three displays. Wayland really makes life difficult here because the software needs to always put the playfield on one display, the backglass on another, and the "dot matrix display" window on a third. That's a big no-no with Wayland. Fortunately KDE has window rules as a workaround. Sway and Hyprland allow similar rules. Mutter on Gnome has no equivalent. I'm guessing this would mess up other games as well, like multi-screen flight simulators or driving games. It would be really nice if user-trusted apps could be granted permissions on an app-by-app basis to allow absolute placement of windows for these cases instead of making us jump through hoops.
  • senfiaj 4mo ago
    Yes, exactly. This security paranoia makes the devs' lives much more complicated. I have seen many apps turning off advanced features, such as screen color pickers. Automatation tools can be broken. Apps cant know their window positions, etc. You can see countless dev rants about Wayland and how it's generally unpleasant experience to work with.
    • dormento 4mo ago
      Ah so that's why i cant use the chrome devtools color picker to pick colors off graphics editing software. Makes me mad.
      • senfiaj 4mo ago
        Yes, on Wayland the color picker can only pick inside Chrome window.
  • kmeisthax 4mo ago
    Ironically, the use case you described is exactly the sort of thing Wayland really excels at - if you're willing to write your own compositor. There's plenty of embedded devices that ship with an extremely simple Wayland compositor that does exactly this. It opens up one app, accepts as many windows from that app as it has displays, and renders one window per display. That's that. There's no super-secret desktop that could wind up accidentally displaying if the app crashes or gets its window accidentally moved about, because there's no desktop and no moving any of the windows. You just take output from an app and put that on the display, then send input back to it.
• branon 4mo ago
  Ah, for some reason I figured this was a minor bug that'd be fixed eventually. Wayland windows are never allowed to spawn always-on-top? Sort of lame. If the logic is that it's the window manager's job to set window rules for this, fine, but in that case Plasma should probably ship with preconfigured rules matching the Chrome/Firefox PiP window. I also find the lack of an Xlib-compatible macro API disruptive but I usually run an X11 session inside Xvnc for this purpose anyway.
• Zardoz84 4mo ago
  Strange... with Firefox in KDE/Plasma just works.
  • krs_ 4mo ago
    I definitely have to right click on the window in the taskbar and select Always Keep On Top with Firefox on Plasma Wayland. Not too big a deal but would be nice if it was something Firefox could just set on its own.
• babypuncher 4mo ago
  > Chrome "picture in picture" window doesn't stay on top when I click somewhere else since Wayland doesn't allow windows to stay on top. Wayland doesn't allow apps to force themselves to be always on top. I would argue that it is up to the window manager to provide this functionality at the discretion of the user. Kwin does this.
  • account42 4mo ago
    I would argue that software that I choose to install already has my discretion and should not be limited by the windowing system in what it can do.
• deleted 4mo ago
  [deleted]
• jimmaswell 4mo ago
  Isn't it also impossible to spawn a window in the last place it was open (or any arbitrary point) because you're not allowed to know or change where your window is by design? Nonsense like that makes me dread having to eventually use it.
  • ranger_danger 4mo ago
    They "fixed" that by implementing multiple conflicting and optional experimental extensions that may or may not randomly be supported by your particular WM/DE, and may or may not be DE-specific protocols in the first place. https://wayland.app/protocols/ https://wayland.app/protocols/
    • redeeman 4mo ago
      are there really multiple confliction extensions? I thought they finally actually agreed on a protocol to do it?
• killerstorm 4mo ago
  There is some resource leak in Chrome / Wayland combo, I mysteriously run out of memory after few days of keeping several Chrome windows. On X11 Chrome can keep going pretty much indefinitely
• foresto 4mo ago
  My Wayland pet peeve: It still lacks keyboard LED control, so unprivileged X11 programs that use the Scroll Lock light as an indicator cannot be ported to Wayland. This Plasma change is going to be painful for me. I wonder if there's an up-to-date list of Wayland shortcomings.
  • teo_zero 4mo ago
    > unprivileged X11 programs that use the Scroll Lock light as an indicator I didn't know such apps existed! What do they use it for?
    • foresto 4mo ago
      One use case is a new message indicator. Unlike icons on the desktop, keyboard lights are visible even when a full-screen application is running, or when we're to the side of or across the room from the computer, or when the display is asleep. I depend on this for my daily communications. Another use case is for keyboard macro utilities to indicate the state of layers, modifier modes, or multi-keystroke input sequences. Others surely exist, since hardware lights can indicate just about anything, and are especially valuable where visibility is important. Even shell scripts can use them on X11, via the xset command.
      • JCattheATM 4mo ago
        Which programs can be configured in this way? Something custom you wrote?
  • redeeman 4mo ago
    assign yourself permission to the device(may or may not happen by default depending on your distribution), and you can actuate it in /sys/class/leds/inputXX::scrolllock/brightness. probably also exists other tools to do it. this is then generic linux LED framework
    • foresto 4mo ago
      I am aware of sysfs LED controls. They don't solve this problem, because access to them requires privileges (or permissions assigned by someone with privileges). It's not reasonable to expect that, just as it's not reasonable to expect a sysadmin to grant users permission to the keyboard device node before they can type anything. Moreover, granting permissions on the sysfs nodes won't distinguish between a user who is logged in to the current virtual console and one who is not. Wayland correctly delegates keyboard ownership to compositors, but they have no way to expose the keyboard's outputs (the LEDs) because Wayland hasn't yet defined a protocol for doing so. X11 has a protocol for this, and X servers handle it just fine. They account for different users and LED states on each virtual console, and do not require clients to have any special permissions. It's an area where Wayland fails to be a suitable replacement.
• teo_zero 4mo ago
  > doesn't allow windows to stay on top. Are you sure that windows that, without your consent, are allowed to stay on top and grab your input are a good idea? And spawned by Chrome? As if we hadn't already enough ad-ware, click-harvesters, and spoofed dialogs popping up everywhere! I know there is a couple of legitimate uses for this, but the ways it can be abused are vastly more. I think the sensitive default should be to block it, and allowing it should be behind some user's conscious action. Yes, it adds some friction to some workflows and it takes a bit to get accustomed to. But it doesn't deserve the label "security paranoia".
  • account42 4mo ago
    Are you aware that if software misuses the capabilities its given by the system you can choose to stop using that software?
    • teo_zero 4mo ago
      True. But it's often all or nothing: you can't surf the web without the ads.
    • orbital-decay 4mo ago
      You can't do anything about a compromised app or JS from a random website. I always find it weird when people attack Wayland's security model, more isolation is obviously a great idea, as demonstrated by supply chain attacks in the recent decade. It's that Wayland's design, implementation, their attitude, and everything else about it is terrible. It could have been implemented without compromising on features or convenience by explicitly specifying minimalistic controlled side channels in their security model from the start, instead of shifting it onto ad-hoc implementations. And of course the windowing system is already too large of an attack surface. Many people are thinking about going full Qubes due to the current realities, while the others live in denial and call even window isolation "paranoia". Fascinating.
      • chadgpt3 4mo ago
        Turn off the web browser feature that allows JS in an advertisement in a background tab to globally grab your input.
• throwaway7356 4mo ago
  > Wayland doesn't allow windows to stay on top I use Wayland and it has a "stay on top" option for windows.