Windows managers? Consistent window decorations? Thousands of applications? Consistent performance? Redshift? Global keybindings?
Windows managers? Consistent window decorations? Thousands of applications? Consistent performance? Redshift? Global keybindings?
Sway/wlroots.
> Consistent window decorations?
This is up to individual compositors and toolkits.
> Thousands of applications
Like what? Any that rely on X specific behaviour run via XWayland.
> Consistent performance
Wayland in theory should be faster than X, but again, this depends on compositor.
> Redshift
Gnome has night-light on Wayland already. KDE I think just added it.
> Global keybindings
There are proposals to allow better negotiation of key bindings. But I think it's a bonus that applications can't listen into keys when they're not in focus.
Wayland ecosystem is literally decades away from being usable and it's very unlikely to survive those decades beyond maybe being a niche project for some special purpose devices, not linux desktop though.
As for those other things you mention (xprop, etc.), I don't even know what they are, so I assume I've never used them.
I think you underestimate the degree to which desktop Linux users just want a working system with sane defaults. Maybe you personally value having all the knobs to twiddle, but I'd suggest you're an outlier.
I maintain an embedded Linux system which uses Wayland as a compositor for Qt. I use sysfs to EG turn off cursors and set the display mode so I can blit a splashscreen. And sysfs can be used to rotate the console, change display modes, etc..
On my desktop I don't use any of the tools you're listing and haven't needed then for almost 12 years. The wm handles that for me.
I have used Linux desktops for years and have quite literally never used any of those things (except for non-Gnome DE, which was slightly less "don't make me think" so I eventually went back to gnome). Yes, even xterm. Other tools might have been shelling out to those other utilities you mentioned for me, I guess?
Point is, there are at least some reasonable use cases that don't engage with that stuff. I truly don't know how much of the display stack of my current distro is X or Wayland-related code; I have never had reason to care. I don't have a dog in this particular fight, but there are lots of users who use Linux desktops not because they are customizable, modular, or whatever, but because a) it's a free OS, and b) it's similar to environments we target for development at our jobs. Despite the vocal-ness of customization advocates, I suspect that the vast majority of desktop Linux users are "dark matter" that fall into this category.
There's a large group of users that goes to great lengths to customize their desktop experience. This kind of change understandably frustrates them. But it's important to understand that many of us just don't care very much.
Can it run gnome-terminal and Firefox? Can I switch resolutions and do multiple displays? That covers a vast majority of what I ever need from a graphical desktop. Beyond that I don't really care how the sausage is made.
I would argue that not having to use those tools to have a happy working environment makes it further advanced, rather than behind.
There are applications that do not run as a window, in present I have a global shortcuts that run a bash or python script, I know I am a power user so I will need a way to whitelist my use case.
GNOME and I'm pretty sure KDE too has a method to set custom keyboard shortcuts that can execute commands.
Yeah, that is the problem with Wayland: the solution to many missing features you get out of the box with X largely depends on the environment you are using.
Wayland needs to offer full access to "power users applications" if not we end up where Windows will be more friendly for the users that need this type of applications
> Sway/wlroots.
So you either have to use one of the prescribed Wayland window managers, or completely rewrite your favourite window manager (remembering to include all of the bonus responsibilities it has now for everything the Wayland developers decided was "out of scope and the compositor's responsibility").
Alright, five years of work and debugging later...
> > Consistent window decorations?
> This is up to individual compositors and toolkits.
So it won't be consistent.
> > Consistent performance
> Wayland in theory should be faster than X, but again, this depends on compositor.
So this is the part where you go back to the window manager you wrote in step 1, and fix all the performance problems (collectively, over and over again, for every window manager that exists), right?
> > Redshift
> Gnome has night-light on Wayland already. KDE I think just added it.
Great! What if I'm not using Gnome or KDE? Right, I need to code that into my window manager too...
The decision to leave window decorations up to the client application rather than the window manager is incomprehensible to me. It just doesn't make any sense so far as I can tell.
I don't want to run GNOME or KDE to get redshift behaviour; I want to run a window manager written in Lisp, with a console, emacs & Firefox. Everything else is a distraction from getting work done.
I agree that not allowing clients to listen to all keys by default is good; I disagree that not providing a mechanism for the end user to grant such access is a good idea. It's his computer — let him run what he wants.
https://github.com/sdilts/mahogany
Maybe you're interested in helping?
>Consistent window decorations?
We have a protocol for this for compositors that want to support it: https://gitlab.freedesktop.org/wayland/wayland-protocols/tre...
>Redshift?
Works on GNOME, KDE and Sway.
>Global keybindings?
We prefer to let users configure those in their compositor's configuration file.