7 ms·

Funny, I was literally just looking at this issue today. I switched to wayland a few weeks ago, just because it seems to save a lot of battery power. But so muc

Funny, I was literally just looking at this issue today. I switched to wayland a few weeks ago, just because it seems to save a lot of battery power. But so much basic functionality is still broken it's infuriating. And then so many things seem to follow the "unix functionality" and as a result they're half baked tools that aren't really working properly IMHO. A lot of these issues have fixes or workarounds directly in KDE. For reference I'm using sway. swayidle is an idle daemon, where the maintainer doesn't think that it matters whether its connected to power or not. You're supposed to create your own scripts around it that handles ac connect and disconnects. There's a tool to do flux like color warmth setting. One of them doesn't allow you to toggle, so you have create your own toggle script that kills or restarts it. The other one is controllable, but doesn't actually account for time or timezone. XWayland has had 2 or 3 patches to handle hidpi when the main wayland screen has fractional scaling, none of them are merged and they seem hardly active. KDE works around that by allowing you to turn it off for xwayland clients. Sway just passes it down and blurs everything. When I exit a wayland session and then restart it the screen locks up. This doesn't happen with normal X. And then there is electron. Slack is not the only app that ignores electron settings and doesn't run with wayland support. In chrome and electron it's supposedly supported but you have to toggle it yourself? What is this madness? These things seem like basic functionality for me. I don't really get it. Sure, maybe I shouldn't expect a proper experience for random sway tools, so that makes the first two points irrelevant. But the fact that years in they still haven't found a proper solution on passing down hidpi for xwayland? That's incomprehensible for me.

yjftsjthsd-h 4y ago
> And then so many things seem to follow the "unix functionality" and as a result they're half baked tools that aren't really working properly IMHO. I'm going to disagree pretty strongly with that. In fact, I think most of its problems are that it threw the Unix philosophy out the window. While it's true that it suffers from having made everything a implementation detail that can theoretically be plugged in with a different component, the problem is that they forced everything important to go through the compositor, which bottlenecks composiblilty and doesn't allow you to actually replace individual components without support from the (usually incomplete) monolith in the middle.
- falseassertions 4y ago
  Except that nearly everything that makes the usual years-out-of-date Wayland gripe lists here are ALL specified protocols now, it's just a matter of time until they're implemented widely enough to put this to rest. Fractional scaling, hotkeys, gamma control, screen capture, etc, all have protocols.
  - yjftsjthsd-h 4y ago
    I don't believe that this will happen in practice in any event. First, implementations have... let's say personality conflicts? That is, I would be shocked if GNOME replaces its screenshot protocol with the "standard" any time soon. Second, even when it's true it requires every single compositor to actually connect all the bits up. For instance, I don't use QWERTY if I can help it. So a little while back, I tried a new compositor that was based on wlroots, which supports changing keyboard layouts. Guess what I couldn't do, because that specific compositor hadn't gotten to plumbing that specific feature through? Guess what works on every single X11 window manager, no matter how barebones, because X11 can manage separation of concerns?
  - adgjlsfhk1 4y ago
    hdr is still mia
- kaba0 4y ago
  As opposed to the single, so-huge-that-nvidia-ships-binary-blobs-for-it xserver implementation?
  - yjftsjthsd-h 4y ago
    Yes, actually; the X server was awful, but it was a single contained point of awfulness that allowed everything else to be trivially interoperable. Breaking that apart could have been good except that the way they actually did it mixed far too many concerns into the graphical server (compositor), so while we have more of them, in practice you can't actually mix and match the rest of the system anymore.
falseassertions 4y ago
So your issues are basically exclusively with X, X clients and most of all, proprietary X clients that are using major-revs-old versions of Electron. Yeah, that sounds like a real drag, glad I use Wayland and only have Ledger Live that I'm forced to use twice a year. > But the fact that years in they still haven't found a proper solution on passing down hidpi for xwayland? That's incomprehensible for me. It's crazy how this is incomprehensible despite it being explained quite clearly every time it comes up. There might be patches, but they are incomplete and they are kludgy and the experts that could push it through ARE WORKING ON IMPROVING WAYLAND. If it remains incomprehensible, go read through the fractional scaling protocol merge and see how much discussion there was for designing that protocol, not even considering the X interop scenario you want. You can: (1) try really hard to convince volunteers to spend huge amounts of time supporting something they deemed dead years ago, or (2) try to get shitty proprietary companies to, you know, fund a single developer part time to do basic maintenance, (3) use less crappy tools and/or demand that you aren't forced to use shitty tools. Why is it ALWAYS that people reach for (1)? I swear to god I hope it's folks that don't do OSS development themselves. The entitlement and ignorance makes me head spin. But hey, random OSS devs are much easier to rage at than your CTO, or some random "chat startup" that doesn't give a fuck. So rock on with your ire against OSS devs not working on your explicitly deprecated scenario.
cycomanic 4y ago
If you want full desktop integration why are you using sway. Most of the functionality you're talking about requires writing scripts if you used i3 or awesome WM on X11 as well so has nothing to do with wayland. Regarding exiting and restarting a wayland session, how do you do it? GDM, the console? It obviously works for most other people so it seems you're encountering a bug related to your hardware or setup so you could file a bug report with the appropriate project (again doesn't really seem like a wayland issue though).
nextaccountic 4y ago
> For reference I'm using sway. swayidle is an idle daemon, where the maintainer doesn't think that it matters whether its connected to power or not. You're supposed to create your own scripts around it that handles ac connect and disconnects. > There's a tool to do flux like color warmth setting. One of them doesn't allow you to toggle, so you have create your own toggle script that kills or restarts it. The other one is controllable, but doesn't actually account for time or timezone. I used to write little tools like his and my ~/bin is still littered with scripts from 10 years ago Nowadays I want this functionality to work by default and I won't settle for a less usable system
gigatexal 4y ago
scripting around hobby projects to fit your needs is the hacker ethos/mindset/what makes using linux/unix fun. But give the ecosystem time and Sway and its ecosystem will be just as good as X and i3 is.
CameronNemo 4y ago
The other one is controllable, but doesn't actually account for time or timezone. Alright first off: file a bug! How am I supposed to know there is a user with a problem, if they don't tell me! That said not sure what you mean by this exactly... gammastep 100% does account for the local time. But it does choose the time of day to transition based on the location. Are you in a different location than your timezone is set to?
WhyNotHugo 4y ago
> For reference I'm using sway. swayidle is an idle daemon, where the maintainer doesn't think that it matters whether its connected to power or not. You're supposed to create your own scripts around it that handles ac connect and disconnects. Yeah, the existing tools are pretty low level. For now you need to write your own "scripts" for matching different states from different places (e.g.: idle + battery charging state). Hopefully someone will build higher level tools on top of the existing tools. The APIs are all there (i.e.: there are no technical limitations, it's just that nobody has done it yet). > There's a tool to do flux like color warmth setting. One of them doesn't allow you to toggle, so you have create your own toggle script that kills or restarts it. The other one is controllable, but doesn't actually account for time or timezone. Try gammastep.
kevincox 4y ago
I've been using GNOME on Wayland for over a year and have literally none of these issues other than X fractional scaling not being great. But even then fractional scaling is good enough that I generally don't notice it. (But all of my daily apps are Wayland native) > swayidle is an idle daemon, where the maintainer doesn't think that it matters whether its connected to power or not Sounds like a problem with the tool, not Wayland. > color warmth setting This is a general issue on Wayland but GNOME has this built in. I'm surprised that KDE doesn't. > In chrome and electron it's supposedly supported but you have to toggle it yourself? I guess Chromium's Wayland support isn't considered production ready? I don't use Chromium often but running on XWayland hasn't bothered me much. I guess this would be more annoying if it was your primary browser.
whywhywhywhy 4y ago
Doesn’t this have some sort of performance or battery impact if every action is firing off a script interpreter middle manager to action basic things.
vorpalhex 4y ago
It's just early. It's fast to make little scripts and glue it together yourself, and until folks really enumerate use cases and build to meet them, it's going to feel unfinished. It takes years to build out a big project like this. If you want "just works", stick to X and a mature desktop environment like KDE or Gnome for now (especially if you do any gaming).
- hedora 4y ago
  > It's just early. Have we hit the two decade mark yet? This stuff “just worked” in the late 90’s (and probably earlier, assuming access to unix workstation hardware) with X11, when it was roughly the age Wayland is now.
  - vorpalhex 4y ago
    I have two displays on my computer, one is 4k and the other is 1080p. One has HDR. One is 400 nits brightness, the other is not. Games are built across several engines with an amazing collection of rendering technologies. We have apps that embedded web browsers. I'm sure if you restricted yourself to strictly first party native applications and a single display within one or two resolutions and no DPI scaling, Wayland probably meets most of your needs now.
  - ComputerGuru 4y ago
    This is the problem with making a wholesale rewrite and not including good (and complete!) backwards compatibility for the duration of the transition.
    - kaba0 4y ago
      What’s not good and incomplete about xwayland?
      - kelnos 4y ago
        XWayland doesn't really help you with things that are part of the desktop environment. You can't run a desktop background/icons manager or a dock/panel in XWayland, as it won't have access to the kind of information it needs to implement all its features.
jchw 4y ago
The reason why Chrome and Electron still need a flag is simple: Chrome still has a decent chunk of work to do before Wayland is supported to the same degree as X11. They had a lot of false starts: it took years before Wayland support actually got upstreamed in any regard. Likewise for Electron. It does generally work to the point of daily-driver usability today with stable Chrome and Electron, but some apps are shipping old and out-of-support versions of Electron, so unfortunately it has become a bit of a waiting game. Anyways, you can't actually do proper DPI virtualization for X11 apps because afaik there is no protocol for apps to communicate the scale that they are actually rendering at, so there will never be full support for mixed or fractional DPI in XWayland to the same degree that it is supported in Wayland. I'm not 100% sure there would be a point to making such a protocol at this point, since blurry-but-correct surfaces seems like an OK trade-off to keep things working in the long term. If you run real X11 with mixed DPI or fractional DPI, you get quite a range of potential failure cases depending on what apps you run. At this point most of my screen is filled with native Wayland apps, and Electron apps that use reasonably up-to-date Electron (like VS Code), so it's rare to see a blurry window.
- yjftsjthsd-h 4y ago
  > Chrome still has a decent chunk of work to do before Wayland is supported to the same degree as X11. I'm not doubting you, but given that ChromeOS uses Wayland I'm very confused by this.
  - Karellen 4y ago
    I'm not familiar with the situation, but my guess would be that ChromeOS has created its own Wayland compositor with a bunch of private protocol extensions that Chrome on ChromeOS uses to get stuff done. But for some reason or another, those protocol extensions are not suitable for submitting as new public extensions for other compositors to implement. Or they are suitable for submission, but the official extension roadmap already has different extensions in the works (but not yet complete) that will do the same thing.
    - jchw 4y ago
cbushko 4y ago
Please help the community and make sure that these issues are documented in Github/whatever issue tracker. Or if you have the skills please contribute back and fixes these things that bug you!
kaba0 4y ago
> And then there is electron. Slack is not the only app that ignores electron settings and doesn't run with wayland support I wouldn’t be surprised if slack just ships with a much older chrome build that wasn’t built with wayland support. Also, have a look at Gnome’s wayland offering. It is by far the most complete as of yet.
- smaddock 4y ago
  Slack tracks close to the latest releases of Electron. Election also tracks close to the latest Chromium releases [0]. [0] https://releases.electronjs.org https://releases.electronjs.org
Arnavion 4y ago
>For reference I'm using sway. swayidle is an idle daemon, where the maintainer doesn't think that it matters whether its connected to power or not. You're supposed to create your own scripts around it that handles ac connect and disconnects. >One of them doesn't allow you to toggle, so you have create your own toggle script that kills or restarts it. If you're not a fan of making scripts then sway (and wlsunset I assume) is not for you. My sway install is held together by a myriad of scripts - keybindings are handled by a script, starting programs via bemenu goes through a script, sway itself is started by a script, etc. That's just how this compositor and its ecosystem are designed - they're for people who want the software itself to do the smallest possible thing with the least possible assumptions so that the user can do whatever they want to fill in the rest.
- ComputerGuru 4y ago
  The problem isn’t that it’s held together by individual scripts and apps that one can replace or hack at. The problem is that none of these pieces ship in place. Ideally you’d have some sort of offering that gives you a reasonable starting place with all these composable pieces in place, and then you can hack/replace/add/remove as needed. Everyone starting from scratch doesn’t make sense. It’s like shipping a Unix system with no app doing it’s own paging because the devs rightly expect you to use some other tool to page output for you, but there’s no less/more installed (and no back buffer in the terminal or terminal emulator to boot). Then you complain and the answer is that you’re supposed to write your own (or research, download, compile, and install something someone else might have hacked up).
  - uberduper 4y ago
    afaik there are various distros that will give you a preconfigured out of the box swaywm based desktop env. Garuda linux comes to mind. The sway wiki is pretty detailed and iirc has a helpful page full of options for various "not the compositor's job" tasks like notification daemon, app launcher, etc.
  - lapinot 4y ago
    > The problem is that none of these pieces ship in place. Sway is not a desktop environment. What you are describing is a desktop environment. I too would like a sway-based desktop environment. Let's stop complaining that sway is not what it is or that somehow this is related to wayland. This whole thing is just a consequence that writing cohesive graphical/desktop software is tedious and that tinkerers cannot rely on the myriad of Xorg desktop environment, in particular the modular ones like lxde/xfce to mix and match components. > Then you complain and the answer is that you’re supposed to write your own Yes, obviously. No-one is saying this would be a bad project. And if you blatantly misunderstand their project's scope it's no wonder you're getting dry responses.
hedora 4y ago
Regarding randomly blurry UIs: XFree86 (and later, x.org) have always had better support for hidpi rendering than MacOS X and Windows (by my definition, which is based on the quality of tear-free vector, font and bitmap rendering at non-standard DPIs while using mainstream hardware). The wayland developers apparently couldn’t figure out how to read the X11 manual. Why expect them to reimplement it in a superior way?
- mijoharas 4y ago
  The thing that made me switch to Wayland was having two monitors with different DPI, which was unsupported by X.
  - p_l 4y ago
    IIRC, a big chunk of that was the trend that led to wayland causing "effective deprecation" of some more complex aspects of X11, like replacing multihead with windows into unified frame buffer (which now required single DPI for all screens while multihead allowed completely different settings)
  - badsectoracula 4y ago
    Xorg does support having multiple monitors with different DPI, however applications need to use the RandR extension to obtain that per-monitor information as an older API that provided per-screen information (which doesn't make sense for Xinerama anyway) is hardcoded for backwards compatibility reasons (an attempt was made a couple of Xorg releases ago to remove the hardcoded value and present a more appropriate value but it broke a bunch of programs so it was reversed).
- ElectricalUnion 4y ago
  Intent is one thing, whenever userland GUI developers actually uses the API the intended way is another. It's not a bug, it's just a undocumented feature. If everyone uses the API the "wrong way", now you're stuck supporting the "wrong way" or everything breaks and people WILL complain.
- ibotty 4y ago

yjftsjthsd-h 4y ago

> And then so many things seem to follow the "unix functionality" and as a result they're half baked tools that aren't really working properly IMHO. I'm going to disagree pretty strongly with that. In fact, I think most of its problems are that it threw the Unix philosophy out the window. While it's true that it suffers from having made everything a implementation detail that can theoretically be plugged in with a different component, the problem is that they forced everything important to go through the compositor, which bottlenecks composiblilty and doesn't allow you to actually replace individual components without support from the (usually incomplete) monolith in the middle.

falseassertions 4y ago
Except that nearly everything that makes the usual years-out-of-date Wayland gripe lists here are ALL specified protocols now, it's just a matter of time until they're implemented widely enough to put this to rest. Fractional scaling, hotkeys, gamma control, screen capture, etc, all have protocols.
- yjftsjthsd-h 4y ago
  I don't believe that this will happen in practice in any event. First, implementations have... let's say personality conflicts? That is, I would be shocked if GNOME replaces its screenshot protocol with the "standard" any time soon. Second, even when it's true it requires every single compositor to actually connect all the bits up. For instance, I don't use QWERTY if I can help it. So a little while back, I tried a new compositor that was based on wlroots, which supports changing keyboard layouts. Guess what I couldn't do, because that specific compositor hadn't gotten to plumbing that specific feature through? Guess what works on every single X11 window manager, no matter how barebones, because X11 can manage separation of concerns?
- adgjlsfhk1 4y ago
  hdr is still mia
kaba0 4y ago
As opposed to the single, so-huge-that-nvidia-ships-binary-blobs-for-it xserver implementation?
- yjftsjthsd-h 4y ago
  Yes, actually; the X server was awful, but it was a single contained point of awfulness that allowed everything else to be trivially interoperable. Breaking that apart could have been good except that the way they actually did it mixed far too many concerns into the graphical server (compositor), so while we have more of them, in practice you can't actually mix and match the rest of the system anymore.

falseassertions 4y ago

So your issues are basically exclusively with X, X clients and most of all, proprietary X clients that are using major-revs-old versions of Electron. Yeah, that sounds like a real drag, glad I use Wayland and only have Ledger Live that I'm forced to use twice a year. > But the fact that years in they still haven't found a proper solution on passing down hidpi for xwayland? That's incomprehensible for me. It's crazy how this is incomprehensible despite it being explained quite clearly every time it comes up. There might be patches, but they are incomplete and they are kludgy and the experts that could push it through ARE WORKING ON IMPROVING WAYLAND. If it remains incomprehensible, go read through the fractional scaling protocol merge and see how much discussion there was for designing that protocol, not even considering the X interop scenario you want. You can: (1) try really hard to convince volunteers to spend huge amounts of time supporting something they deemed dead years ago, or (2) try to get shitty proprietary companies to, you know, fund a single developer part time to do basic maintenance, (3) use less crappy tools and/or demand that you aren't forced to use shitty tools. Why is it ALWAYS that people reach for (1)? I swear to god I hope it's folks that don't do OSS development themselves. The entitlement and ignorance makes me head spin. But hey, random OSS devs are much easier to rage at than your CTO, or some random "chat startup" that doesn't give a fuck. So rock on with your ire against OSS devs not working on your explicitly deprecated scenario.

cycomanic 4y ago

If you want full desktop integration why are you using sway. Most of the functionality you're talking about requires writing scripts if you used i3 or awesome WM on X11 as well so has nothing to do with wayland. Regarding exiting and restarting a wayland session, how do you do it? GDM, the console? It obviously works for most other people so it seems you're encountering a bug related to your hardware or setup so you could file a bug report with the appropriate project (again doesn't really seem like a wayland issue though).

nextaccountic 4y ago

> For reference I'm using sway. swayidle is an idle daemon, where the maintainer doesn't think that it matters whether its connected to power or not. You're supposed to create your own scripts around it that handles ac connect and disconnects. > There's a tool to do flux like color warmth setting. One of them doesn't allow you to toggle, so you have create your own toggle script that kills or restarts it. The other one is controllable, but doesn't actually account for time or timezone. I used to write little tools like his and my ~/bin is still littered with scripts from 10 years ago Nowadays I want this functionality to work by default and I won't settle for a less usable system

gigatexal 4y ago

scripting around hobby projects to fit your needs is the hacker ethos/mindset/what makes using linux/unix fun. But give the ecosystem time and Sway and its ecosystem will be just as good as X and i3 is.

CameronNemo 4y ago

The other one is controllable, but doesn't actually account for time or timezone. Alright first off: file a bug! How am I supposed to know there is a user with a problem, if they don't tell me! That said not sure what you mean by this exactly... gammastep 100% does account for the local time. But it does choose the time of day to transition based on the location. Are you in a different location than your timezone is set to?

WhyNotHugo 4y ago

> For reference I'm using sway. swayidle is an idle daemon, where the maintainer doesn't think that it matters whether its connected to power or not. You're supposed to create your own scripts around it that handles ac connect and disconnects. Yeah, the existing tools are pretty low level. For now you need to write your own "scripts" for matching different states from different places (e.g.: idle + battery charging state). Hopefully someone will build higher level tools on top of the existing tools. The APIs are all there (i.e.: there are no technical limitations, it's just that nobody has done it yet). > There's a tool to do flux like color warmth setting. One of them doesn't allow you to toggle, so you have create your own toggle script that kills or restarts it. The other one is controllable, but doesn't actually account for time or timezone. Try gammastep.

kevincox 4y ago

I've been using GNOME on Wayland for over a year and have literally none of these issues other than X fractional scaling not being great. But even then fractional scaling is good enough that I generally don't notice it. (But all of my daily apps are Wayland native) > swayidle is an idle daemon, where the maintainer doesn't think that it matters whether its connected to power or not Sounds like a problem with the tool, not Wayland. > color warmth setting This is a general issue on Wayland but GNOME has this built in. I'm surprised that KDE doesn't. > In chrome and electron it's supposedly supported but you have to toggle it yourself? I guess Chromium's Wayland support isn't considered production ready? I don't use Chromium often but running on XWayland hasn't bothered me much. I guess this would be more annoying if it was your primary browser.

whywhywhywhy 4y ago

Doesn’t this have some sort of performance or battery impact if every action is firing off a script interpreter middle manager to action basic things.

vorpalhex 4y ago

It's just early. It's fast to make little scripts and glue it together yourself, and until folks really enumerate use cases and build to meet them, it's going to feel unfinished. It takes years to build out a big project like this. If you want "just works", stick to X and a mature desktop environment like KDE or Gnome for now (especially if you do any gaming).

hedora 4y ago
> It's just early. Have we hit the two decade mark yet? This stuff “just worked” in the late 90’s (and probably earlier, assuming access to unix workstation hardware) with X11, when it was roughly the age Wayland is now.
- vorpalhex 4y ago
  I have two displays on my computer, one is 4k and the other is 1080p. One has HDR. One is 400 nits brightness, the other is not. Games are built across several engines with an amazing collection of rendering technologies. We have apps that embedded web browsers. I'm sure if you restricted yourself to strictly first party native applications and a single display within one or two resolutions and no DPI scaling, Wayland probably meets most of your needs now.
- ComputerGuru 4y ago
  This is the problem with making a wholesale rewrite and not including good (and complete!) backwards compatibility for the duration of the transition.
  - kaba0 4y ago
    What’s not good and incomplete about xwayland?
    - kelnos 4y ago
      XWayland doesn't really help you with things that are part of the desktop environment. You can't run a desktop background/icons manager or a dock/panel in XWayland, as it won't have access to the kind of information it needs to implement all its features.

jchw 4y ago

The reason why Chrome and Electron still need a flag is simple: Chrome still has a decent chunk of work to do before Wayland is supported to the same degree as X11. They had a lot of false starts: it took years before Wayland support actually got upstreamed in any regard. Likewise for Electron. It does generally work to the point of daily-driver usability today with stable Chrome and Electron, but some apps are shipping old and out-of-support versions of Electron, so unfortunately it has become a bit of a waiting game. Anyways, you can't actually do proper DPI virtualization for X11 apps because afaik there is no protocol for apps to communicate the scale that they are actually rendering at, so there will never be full support for mixed or fractional DPI in XWayland to the same degree that it is supported in Wayland. I'm not 100% sure there would be a point to making such a protocol at this point, since blurry-but-correct surfaces seems like an OK trade-off to keep things working in the long term. If you run real X11 with mixed DPI or fractional DPI, you get quite a range of potential failure cases depending on what apps you run. At this point most of my screen is filled with native Wayland apps, and Electron apps that use reasonably up-to-date Electron (like VS Code), so it's rare to see a blurry window.

yjftsjthsd-h 4y ago
> Chrome still has a decent chunk of work to do before Wayland is supported to the same degree as X11. I'm not doubting you, but given that ChromeOS uses Wayland I'm very confused by this.
- Karellen 4y ago
  I'm not familiar with the situation, but my guess would be that ChromeOS has created its own Wayland compositor with a bunch of private protocol extensions that Chrome on ChromeOS uses to get stuff done. But for some reason or another, those protocol extensions are not suitable for submitting as new public extensions for other compositors to implement. Or they are suitable for submission, but the official extension roadmap already has different extensions in the works (but not yet complete) that will do the same thing.
  - jchw 4y ago

cbushko 4y ago

Please help the community and make sure that these issues are documented in Github/whatever issue tracker. Or if you have the skills please contribute back and fixes these things that bug you!

kaba0 4y ago

> And then there is electron. Slack is not the only app that ignores electron settings and doesn't run with wayland support I wouldn’t be surprised if slack just ships with a much older chrome build that wasn’t built with wayland support. Also, have a look at Gnome’s wayland offering. It is by far the most complete as of yet.

smaddock 4y ago
Slack tracks close to the latest releases of Electron. Election also tracks close to the latest Chromium releases [0]. [0] https://releases.electronjs.org https://releases.electronjs.org

Arnavion 4y ago

>For reference I'm using sway. swayidle is an idle daemon, where the maintainer doesn't think that it matters whether its connected to power or not. You're supposed to create your own scripts around it that handles ac connect and disconnects. >One of them doesn't allow you to toggle, so you have create your own toggle script that kills or restarts it. If you're not a fan of making scripts then sway (and wlsunset I assume) is not for you. My sway install is held together by a myriad of scripts - keybindings are handled by a script, starting programs via bemenu goes through a script, sway itself is started by a script, etc. That's just how this compositor and its ecosystem are designed - they're for people who want the software itself to do the smallest possible thing with the least possible assumptions so that the user can do whatever they want to fill in the rest.

ComputerGuru 4y ago
The problem isn’t that it’s held together by individual scripts and apps that one can replace or hack at. The problem is that none of these pieces ship in place. Ideally you’d have some sort of offering that gives you a reasonable starting place with all these composable pieces in place, and then you can hack/replace/add/remove as needed. Everyone starting from scratch doesn’t make sense. It’s like shipping a Unix system with no app doing it’s own paging because the devs rightly expect you to use some other tool to page output for you, but there’s no less/more installed (and no back buffer in the terminal or terminal emulator to boot). Then you complain and the answer is that you’re supposed to write your own (or research, download, compile, and install something someone else might have hacked up).
- uberduper 4y ago
  afaik there are various distros that will give you a preconfigured out of the box swaywm based desktop env. Garuda linux comes to mind. The sway wiki is pretty detailed and iirc has a helpful page full of options for various "not the compositor's job" tasks like notification daemon, app launcher, etc.
- lapinot 4y ago
  > The problem is that none of these pieces ship in place. Sway is not a desktop environment. What you are describing is a desktop environment. I too would like a sway-based desktop environment. Let's stop complaining that sway is not what it is or that somehow this is related to wayland. This whole thing is just a consequence that writing cohesive graphical/desktop software is tedious and that tinkerers cannot rely on the myriad of Xorg desktop environment, in particular the modular ones like lxde/xfce to mix and match components. > Then you complain and the answer is that you’re supposed to write your own Yes, obviously. No-one is saying this would be a bad project. And if you blatantly misunderstand their project's scope it's no wonder you're getting dry responses.

hedora 4y ago

Regarding randomly blurry UIs: XFree86 (and later, x.org) have always had better support for hidpi rendering than MacOS X and Windows (by my definition, which is based on the quality of tear-free vector, font and bitmap rendering at non-standard DPIs while using mainstream hardware). The wayland developers apparently couldn’t figure out how to read the X11 manual. Why expect them to reimplement it in a superior way?

mijoharas 4y ago
The thing that made me switch to Wayland was having two monitors with different DPI, which was unsupported by X.
- p_l 4y ago
  IIRC, a big chunk of that was the trend that led to wayland causing "effective deprecation" of some more complex aspects of X11, like replacing multihead with windows into unified frame buffer (which now required single DPI for all screens while multihead allowed completely different settings)
- badsectoracula 4y ago
  Xorg does support having multiple monitors with different DPI, however applications need to use the RandR extension to obtain that per-monitor information as an older API that provided per-screen information (which doesn't make sense for Xinerama anyway) is hardcoded for backwards compatibility reasons (an attempt was made a couple of Xorg releases ago to remove the hardcoded value and present a more appropriate value but it broke a bunch of programs so it was reversed).
ElectricalUnion 4y ago
Intent is one thing, whenever userland GUI developers actually uses the API the intended way is another. It's not a bug, it's just a undocumented feature. If everyone uses the API the "wrong way", now you're stuck supporting the "wrong way" or everything breaks and people WILL complain.
ibotty 4y ago