8 ms·

Man, I wish it was just that. Using Qt apps under Gnome on Wayland can break in weird ways (e.g. in one case I saw popup menus opening in weird places or disap

Man, I wish it was just that. Using Qt apps under Gnome on Wayland can break in weird ways (e.g. in one case I saw popup menus opening in weird places or disappearing entirely). Meanwhile, because window decorations under Gnome are client side, the behaviour is weird and inconsistent (double-click on a Gnome titlebar and it maximizes, but double click on a Qt app titlebar and it doesn't). So maybe switch to KDE? Unfortunately, the idea of a "primary" display simply doesn't exist in KDE on Wayland, which is a major regression for multi-monitor setups. And that's setting aside that KDE on Wayland still crashes on a very regular basis. Under Gnome I've also seen apps like Guake that simply don't work properly due to either bugs in the compositor or limitations in the Wayland protocol (I'm still not sure which), so you need to find workarounds in those cases. In general this leads to distros not enabling Wayland by default in clients and toolkits, even if Wayland is the default display server. For example, on Debian (testing), both Firefox and QT require special environment variables to be set depending on your setup. If you don't set them, those applications just use Xwayland and you lose things like fractional scaling. Force the use of Wayland and you end up with a lot of the issues I mention above. Wayland is really coming along. When it works, it's smooth as butter and works great! Heck, I'd love to use it if only for fractional scaling support. But a lot of things are still very broken and it's still gonna take a while for things to mature.

michaelmrose 6y ago
By primary display do you mean new app windows are created there? If so you can use window rules to force windows to be created on a particular screen. You could put different windows on particular screens or just punt everything to the desired primary monitor. This functionally is also available in i3wm/sway as for_window and as a stand alone application under x called devilspie2.
- CarelessExpert 6y ago
  It's a pretty common feature. Windows, Gnome/X11 and KDE/X11 all have the concept of a "primary" monitor. I believe macOS does as well. The idea is that things like the status bar, top bar, dock, etc, appear on the primary monitor unless configured otherwise. Similarly, new windows preferentially open on the primary monitor. This is existing functionality on all of these desktop environments. In a multi-monitor setup, you designate a monitor as the primary monitor and the desktop automatically "does the right thing" even if you remove and reattach the primary display. KDE on Wayland loses this functionality. The primary monitor is whichever monitor is detected first with no way to control it through configuration. The only workaround is to disable your secondary screen and then re-enable it, and you have to do that every time the desktop launches or the display configuration changes, which is a deal-breaker if you dock/undock regularly (or when the display server crashes). Might there be hacky workarounds that partially fix some of these issues? Maybe. But it's a major functional regression and I'm not willing to invest that effort (especially, again, given the stability issues). BTW, Gnome on Wayland preserves this functionality. But unfortunately, as I mentioned, Qt + Gnome leads to a whole host of other issues.
  - michaelmrose 6y ago
    Logically you would just put the same dock on both monitors and tell it to move all new windows to DP-2 (or wherever), open an issue on their bug tracker asking for this feature to be reinstated and explaining why, and move on. This wouldn't so much be a hacky workaround as using a built in feature that achieves the same result. In my opinion primary monitor is conflating 2 settings that perhaps ought to both exist in an easier to use that windows rules. Open new windows on ____ selected from monitor with mouse cursor, same window as focused application, a selected monitor with the default being same monitor as focused application. Always show panel in place of any other bar yes/no. Unchecked by default. You can have a panel on each monitor and put things of your choosing in each panel or even have a panel on top and below on the same monitor if you like. So what happens if you have a panel on your primary monitor 1 and also on your secondary monitors 2 and 3? Say you unplug the laptop and monitor 3 becomes the only monitor. The most obvious and simple thing would be to show the same things on all 3 including showing a taskbar for the windows just on that particular monitor so that when you undock you can still do the same things. Windows does this for example the only difference is which bar has the tray. The most theoretically correct would seem to be allowing you to set different bars for different configurations but this would be complicated and perhaps little used. What I've suggested would be to give you the ability to set a primary bar that is always displayed hiding any secondary bars that normally appear on that display.
    - CarelessExpert 6y ago
      > This wouldn't so much be a hacky workaround as using a built in feature that achieves the same result. But there's already a built-in feature in KDE/X11 for this. It's just broken in Wayland. It's a feature regression, plain and simple.
      - michaelmrose 6y ago
        So ask them to put it back?
        CarelessExpert 6y ago
- azinman2 6y ago
  I'd imagine this as far as things like docks are concerned? But the idea that I have to write specific windowing rules just to use my computer suggests this has a long way to go. It should 'just work' out of the box.
  - michaelmrose 6y ago
    Just work doesn't mean it just works as you personally desire. It means just works in a consistent predictable fashion that is suitable for use not desirable for your taste or matching behavior on windows. Personally I expect windows to show up on the same monitor as the currently focused window or the cursor and having it pop to a primary monitor would be from my perspective a defect. I would have to test but I think that outside of gnome this is actually how the majority of linux environments work out of the box. You don't have set a windows rule in the settings gui just to use your computer. You have to set a windows rule in the settings gui for your computer to work in the fashion that you prefer. That you regard this setting as essential doesn't mean that it actually is just that you strongly prefer it.
coliveira 6y ago
> When it works, it's smooth as butter and works great Come on, Wayland was released 12 years ago! And it still has all kinds of problems that don't make it qualify even for beta software. I'm highly skeptical that Wayland will ever be as useful as X11 is right now.
- CarelessExpert 6y ago
  In all fairness, my experience is that most of the issues are in the broader ecosystem at this point. Wayland, itself, is just a protocol. The display servers are just the display servers. But then you have Gtk and Gnome, Qt and KDE, software like Firefox and Chrome, etc. All of those have to updated as well, and while Wayland the protocol, the display servers, and a lot of the suite of infrastructure around it is in pretty good shape, the toolkits and clients and so forth all still need a lot of work. And you only need to look at the Python 3 transition to see how hard it is to shift a whole ecosystem. So I'm willing to cut the Wayland guys some slack. But it does mean there's still a ways to go, yet, before things are ready for prime time.
  - michaelmrose 6y ago
    The perspective that wayland is just a protocol and doesn't need to address real issues is why it has so many of them to start with.
    - CarelessExpert 6y ago
      That I completely agree with. The folks involved in designing the Wayland protocol seemed to have shed a lot of key features in the name of simplicity or security, forgetting that the solution actually has to meet real, human user needs. Those needs include things like screenshots and screensharing, global hotkey binding, etc, etc. To address that, we now have a range of extension protocols, which is creating fragmentation. The CSD-vs-SSD debate is a perfect example. Things are slowly coalescing--PipeWire is maturing, for example, filling some key gaps--but it's taking time and meanwhile IMO the ecosystem continues to be too immature for broad adoption.
ubercow13 6y ago
>Using Qt apps under Gnome on Wayland can break in weird ways Same on sway. I think the relevant bug report is this [1] but there is no traction and the patch doesn't really work. Qt5 is probably not going to receive any attention now too, so I'm not holding my breath. [1] https://bugreports.qt.io/browse/QTBUG-87303 https://bugreports.qt.io/browse/QTBUG-87303
- floatboth 6y ago
  Oh hey, a link to my bug report :) someone else in the thread mentioned that the KDE devs have patches for Qt that unfuck the menus, and they're included in Arch Linux now or something..? Upd: well, that problem doesn't seem to be fixed there, still no constraints are set on the kde/5.15 branch
cycomanic 6y ago
Maybe this is a Gnome issue? I've been using sway as my main driver for 2 (?) years now and I don't encounter any of the issues that you see. I'm running with firefox and most other apps forced to wayland and was actually surprised how easy it was. The main issues I encounter are about screen sharing. At the moment it does not work for wayland apps (i.e. wayland apps don't show up in the share this). Supposedly there is a way around it, but I've not yet needed to investigate. The other issue is OBS not working (I guess also because of screensharing). And the third issue is some weird bug in Zoom, where if I open the participant or chat window, it becomes extremely laggy. So much so that I can't really type in the chat window because there is such a strong lag, that I finished typing before the word appears. Similarly the video feed becomes choppy. One other issue was that Pycharm was having issue opening some menus/windows but that seems to have been fixed now.
- turminal 6y ago
  > Maybe this is a Gnome issue? Definitely a Gnome issue.
- CarelessExpert 6y ago
  > Maybe this is a Gnome issue? I actually listed a range of issues. Some are in Gnome. Others are in KDE. Yet others are in the toolkits (e.g. the Qt popup menu problem). And still others are in the applications themselves (e.g. Firefox has a whole menu of Wayland-specific bugs).
  - igneo676 6y ago
    I had a ton of issues with QT menus until the latest patches from KDE hit Arch's QT packages. Fixed them
    - floatboth 6y ago
      Ooh! Interesting! Will look at these. So far I've reported a couple Qt bugs, well, they got priorities but no fix so far: https://bugreports.qt.io/browse/QTBUG-87303 https://bugreports.qt.io/browse/QTBUG-87303 https://bugreports.qt.io/browse/QTBUG-87332 https://bugreports.qt.io/browse/QTBUG-87332 If KDE patches actually make menus work okay, that's great. I've been wondering how KDE deals with the bugginess of the wayland QPA, turns out the answer's simple and not KDE-exclusive, nice. upd: seems like no popup constraint adjustment is set on the kde/5.15 branch. Hopefully there are other improvements though…
donio 6y ago
I dread the day when I will be forced to switch since there is nothing like EXWM for Wayland and it's hard to see how such a thing could be implemented. I don't care for "smooth" or "every pixel is perfect" so to me the trade-offs are all negative.
- eikenberry 6y ago
  There are more traditional window manager type compositor, you might be able to find something more to your tastes in this list... https://github.com/swaywm/wlroots/wiki/Projects-which-use-wlroots https://github.com/swaywm/wlroots/wiki/Projects-which-use-wl... As a happy Openbox user, I'm planning on trying Waybox first I think. Waiting for the next Debian release though.
  - donio 6y ago
    EXWM does some special stuff though. It maps X11 windows in a way that they appear to be Emacs buffers and are managed as such. It also optionally captures certain input from them so that Emacs sequences (for example stuff prefixed by C-x) still work as usual. All this is done in a very granular way to maintain the illusion. So for example if I hit "b" after "C-x" or while the Emacs minibuffer is active then it goes to Emacs but otherwise it goes to the application. And generally it works very well, I've been using it for many years. To do this in Wayland I imagine we'd need to have Emacs act as the compositor and that sounds a bit too crazy... Or perhaps some kind of a proxy-compositor could be used that could be fully driven by Emacs using an rpc protocol. Is there such a thing out there?
    - kaba0 6y ago
      Sway is based on wlroots, which basically implements everything needed for a compositor, making creating “only a wm” similarly easy as it was under X. So I’m sure it can be done.
    - herewulf 6y ago
      The proxy-compositor over RPC sounds workable. This is how the Nyxt browser[1] interfaces its Common Lisp runtime with WebKit. [1]: https://nyxt.atlas.engineer/article/technical-design.org https://nyxt.atlas.engineer/article/technical-design.org
soulofmischief 6y ago
I run GNOME/Wayland on my host and do 100% of my computing inside fully-virtualized VMs running xfce, an actually useful desktop environment. In this way, GNOME 3 actually excels because it's completely void of features and is thus mostly invisible.
- jl6 6y ago
  Out of interest are you doing this using Qubes? And why?
  - soulofmischief 6y ago
    I used to, but my requirements evolved out of Qubes and I ended up replicating most of the Qubes environment over KVM.
    - infokiller 6y ago
      Are you using alternatives to Qubes tools such as the secure clipboard (qvm-copy-to-vm), or just using a lower security setup?
      - soulofmischief 6y ago
        I have some of my own tooling in place, for example with secure clipboard, I have disabled clipboard sharing between VMs and instead wrote host-level ssh+xclip scripts which I hotkeyed.
- forgotpwd16 6y ago
  Why do that rather just run Xfce?
  - carlhjerpe 6y ago
    * Company image * Snapshots * Portability * Isolation Just a few things i could come up with as valid reasons someone would want to do this.
rtpg 6y ago
Ubuntu 21.04 is enabling by default, so I bet loads of issues will bubble up there. The very conservative nature of Ubuntu packaging really holds back things getting fixed in my opinion. It’s hard to have a feedback loop when the biggest desktop distro ends up being super far behind. I get why but I would love an opt-in “rolling release” repo for Ubuntu, as silly as that seems
- CarelessExpert 6y ago
  Switch to Debian unstable? No, it's not quite Ubuntu, but it's a rolling, deb-based release.

michaelmrose 6y ago

By primary display do you mean new app windows are created there? If so you can use window rules to force windows to be created on a particular screen. You could put different windows on particular screens or just punt everything to the desired primary monitor. This functionally is also available in i3wm/sway as for_window and as a stand alone application under x called devilspie2.

CarelessExpert 6y ago
It's a pretty common feature. Windows, Gnome/X11 and KDE/X11 all have the concept of a "primary" monitor. I believe macOS does as well. The idea is that things like the status bar, top bar, dock, etc, appear on the primary monitor unless configured otherwise. Similarly, new windows preferentially open on the primary monitor. This is existing functionality on all of these desktop environments. In a multi-monitor setup, you designate a monitor as the primary monitor and the desktop automatically "does the right thing" even if you remove and reattach the primary display. KDE on Wayland loses this functionality. The primary monitor is whichever monitor is detected first with no way to control it through configuration. The only workaround is to disable your secondary screen and then re-enable it, and you have to do that every time the desktop launches or the display configuration changes, which is a deal-breaker if you dock/undock regularly (or when the display server crashes). Might there be hacky workarounds that partially fix some of these issues? Maybe. But it's a major functional regression and I'm not willing to invest that effort (especially, again, given the stability issues). BTW, Gnome on Wayland preserves this functionality. But unfortunately, as I mentioned, Qt + Gnome leads to a whole host of other issues.
- michaelmrose 6y ago
  Logically you would just put the same dock on both monitors and tell it to move all new windows to DP-2 (or wherever), open an issue on their bug tracker asking for this feature to be reinstated and explaining why, and move on. This wouldn't so much be a hacky workaround as using a built in feature that achieves the same result. In my opinion primary monitor is conflating 2 settings that perhaps ought to both exist in an easier to use that windows rules. Open new windows on ____ selected from monitor with mouse cursor, same window as focused application, a selected monitor with the default being same monitor as focused application. Always show panel in place of any other bar yes/no. Unchecked by default. You can have a panel on each monitor and put things of your choosing in each panel or even have a panel on top and below on the same monitor if you like. So what happens if you have a panel on your primary monitor 1 and also on your secondary monitors 2 and 3? Say you unplug the laptop and monitor 3 becomes the only monitor. The most obvious and simple thing would be to show the same things on all 3 including showing a taskbar for the windows just on that particular monitor so that when you undock you can still do the same things. Windows does this for example the only difference is which bar has the tray. The most theoretically correct would seem to be allowing you to set different bars for different configurations but this would be complicated and perhaps little used. What I've suggested would be to give you the ability to set a primary bar that is always displayed hiding any secondary bars that normally appear on that display.
  - CarelessExpert 6y ago
    > This wouldn't so much be a hacky workaround as using a built in feature that achieves the same result. But there's already a built-in feature in KDE/X11 for this. It's just broken in Wayland. It's a feature regression, plain and simple.
    - michaelmrose 6y ago
      So ask them to put it back?
      - CarelessExpert 6y ago
azinman2 6y ago
I'd imagine this as far as things like docks are concerned? But the idea that I have to write specific windowing rules just to use my computer suggests this has a long way to go. It should 'just work' out of the box.
- michaelmrose 6y ago
  Just work doesn't mean it just works as you personally desire. It means just works in a consistent predictable fashion that is suitable for use not desirable for your taste or matching behavior on windows. Personally I expect windows to show up on the same monitor as the currently focused window or the cursor and having it pop to a primary monitor would be from my perspective a defect. I would have to test but I think that outside of gnome this is actually how the majority of linux environments work out of the box. You don't have set a windows rule in the settings gui just to use your computer. You have to set a windows rule in the settings gui for your computer to work in the fashion that you prefer. That you regard this setting as essential doesn't mean that it actually is just that you strongly prefer it.

coliveira 6y ago

> When it works, it's smooth as butter and works great Come on, Wayland was released 12 years ago! And it still has all kinds of problems that don't make it qualify even for beta software. I'm highly skeptical that Wayland will ever be as useful as X11 is right now.

CarelessExpert 6y ago
In all fairness, my experience is that most of the issues are in the broader ecosystem at this point. Wayland, itself, is just a protocol. The display servers are just the display servers. But then you have Gtk and Gnome, Qt and KDE, software like Firefox and Chrome, etc. All of those have to updated as well, and while Wayland the protocol, the display servers, and a lot of the suite of infrastructure around it is in pretty good shape, the toolkits and clients and so forth all still need a lot of work. And you only need to look at the Python 3 transition to see how hard it is to shift a whole ecosystem. So I'm willing to cut the Wayland guys some slack. But it does mean there's still a ways to go, yet, before things are ready for prime time.
- michaelmrose 6y ago
  The perspective that wayland is just a protocol and doesn't need to address real issues is why it has so many of them to start with.
  - CarelessExpert 6y ago
    That I completely agree with. The folks involved in designing the Wayland protocol seemed to have shed a lot of key features in the name of simplicity or security, forgetting that the solution actually has to meet real, human user needs. Those needs include things like screenshots and screensharing, global hotkey binding, etc, etc. To address that, we now have a range of extension protocols, which is creating fragmentation. The CSD-vs-SSD debate is a perfect example. Things are slowly coalescing--PipeWire is maturing, for example, filling some key gaps--but it's taking time and meanwhile IMO the ecosystem continues to be too immature for broad adoption.

ubercow13 6y ago

>Using Qt apps under Gnome on Wayland can break in weird ways Same on sway. I think the relevant bug report is this [1] but there is no traction and the patch doesn't really work. Qt5 is probably not going to receive any attention now too, so I'm not holding my breath. [1] https://bugreports.qt.io/browse/QTBUG-87303 https://bugreports.qt.io/browse/QTBUG-87303

floatboth 6y ago
Oh hey, a link to my bug report :) someone else in the thread mentioned that the KDE devs have patches for Qt that unfuck the menus, and they're included in Arch Linux now or something..? Upd: well, that problem doesn't seem to be fixed there, still no constraints are set on the kde/5.15 branch

cycomanic 6y ago

Maybe this is a Gnome issue? I've been using sway as my main driver for 2 (?) years now and I don't encounter any of the issues that you see. I'm running with firefox and most other apps forced to wayland and was actually surprised how easy it was. The main issues I encounter are about screen sharing. At the moment it does not work for wayland apps (i.e. wayland apps don't show up in the share this). Supposedly there is a way around it, but I've not yet needed to investigate. The other issue is OBS not working (I guess also because of screensharing). And the third issue is some weird bug in Zoom, where if I open the participant or chat window, it becomes extremely laggy. So much so that I can't really type in the chat window because there is such a strong lag, that I finished typing before the word appears. Similarly the video feed becomes choppy. One other issue was that Pycharm was having issue opening some menus/windows but that seems to have been fixed now.

turminal 6y ago
> Maybe this is a Gnome issue? Definitely a Gnome issue.
CarelessExpert 6y ago
> Maybe this is a Gnome issue? I actually listed a range of issues. Some are in Gnome. Others are in KDE. Yet others are in the toolkits (e.g. the Qt popup menu problem). And still others are in the applications themselves (e.g. Firefox has a whole menu of Wayland-specific bugs).
- igneo676 6y ago
  I had a ton of issues with QT menus until the latest patches from KDE hit Arch's QT packages. Fixed them
  - floatboth 6y ago
    Ooh! Interesting! Will look at these. So far I've reported a couple Qt bugs, well, they got priorities but no fix so far: https://bugreports.qt.io/browse/QTBUG-87303 https://bugreports.qt.io/browse/QTBUG-87303 https://bugreports.qt.io/browse/QTBUG-87332 https://bugreports.qt.io/browse/QTBUG-87332 If KDE patches actually make menus work okay, that's great. I've been wondering how KDE deals with the bugginess of the wayland QPA, turns out the answer's simple and not KDE-exclusive, nice. upd: seems like no popup constraint adjustment is set on the kde/5.15 branch. Hopefully there are other improvements though…

donio 6y ago

I dread the day when I will be forced to switch since there is nothing like EXWM for Wayland and it's hard to see how such a thing could be implemented. I don't care for "smooth" or "every pixel is perfect" so to me the trade-offs are all negative.

eikenberry 6y ago
There are more traditional window manager type compositor, you might be able to find something more to your tastes in this list... https://github.com/swaywm/wlroots/wiki/Projects-which-use-wlroots https://github.com/swaywm/wlroots/wiki/Projects-which-use-wl... As a happy Openbox user, I'm planning on trying Waybox first I think. Waiting for the next Debian release though.
- donio 6y ago
  EXWM does some special stuff though. It maps X11 windows in a way that they appear to be Emacs buffers and are managed as such. It also optionally captures certain input from them so that Emacs sequences (for example stuff prefixed by C-x) still work as usual. All this is done in a very granular way to maintain the illusion. So for example if I hit "b" after "C-x" or while the Emacs minibuffer is active then it goes to Emacs but otherwise it goes to the application. And generally it works very well, I've been using it for many years. To do this in Wayland I imagine we'd need to have Emacs act as the compositor and that sounds a bit too crazy... Or perhaps some kind of a proxy-compositor could be used that could be fully driven by Emacs using an rpc protocol. Is there such a thing out there?
  - kaba0 6y ago
    Sway is based on wlroots, which basically implements everything needed for a compositor, making creating “only a wm” similarly easy as it was under X. So I’m sure it can be done.
  - herewulf 6y ago
    The proxy-compositor over RPC sounds workable. This is how the Nyxt browser[1] interfaces its Common Lisp runtime with WebKit. [1]: https://nyxt.atlas.engineer/article/technical-design.org https://nyxt.atlas.engineer/article/technical-design.org

soulofmischief 6y ago

I run GNOME/Wayland on my host and do 100% of my computing inside fully-virtualized VMs running xfce, an actually useful desktop environment. In this way, GNOME 3 actually excels because it's completely void of features and is thus mostly invisible.

jl6 6y ago
Out of interest are you doing this using Qubes? And why?
- soulofmischief 6y ago
  I used to, but my requirements evolved out of Qubes and I ended up replicating most of the Qubes environment over KVM.
  - infokiller 6y ago
    Are you using alternatives to Qubes tools such as the secure clipboard (qvm-copy-to-vm), or just using a lower security setup?
    - soulofmischief 6y ago
      I have some of my own tooling in place, for example with secure clipboard, I have disabled clipboard sharing between VMs and instead wrote host-level ssh+xclip scripts which I hotkeyed.
forgotpwd16 6y ago
Why do that rather just run Xfce?
- carlhjerpe 6y ago
  * Company image * Snapshots * Portability * Isolation Just a few things i could come up with as valid reasons someone would want to do this.

rtpg 6y ago

Ubuntu 21.04 is enabling by default, so I bet loads of issues will bubble up there. The very conservative nature of Ubuntu packaging really holds back things getting fixed in my opinion. It’s hard to have a feedback loop when the biggest desktop distro ends up being super far behind. I get why but I would love an opt-in “rolling release” repo for Ubuntu, as silly as that seems

CarelessExpert 6y ago
Switch to Debian unstable? No, it's not quite Ubuntu, but it's a rolling, deb-based release.