131–140 of 518 posts
Methodology of Window Management
F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams
29 April 1985
This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme.
The Proceedings were later published by Springer-Verlag in 1986.
http://www.chilton-computing.org.uk/inf/literature/books/wm/...
Earlier quoted context omitted.
>they are effectively gaining control of the Linux userland. but they aren't gaining control by some dastardly power grab, they're gaining control because they're the only ones actually putting in the work. They're simply doing what they think is best for their product, while at the same time contributing their work back to the open source world. That is good, that's how it's supposed to work. The only reason they're…
It seems like a lot of those projects just aren't interested in accepting pull-requests from outsiders. If they were more willing to compromise and cooperate I don't think they'd catch nearly this much flac.
Are there any major x11 features that wayland lacks other than remote operation over a network? I think at one point it locked the refresh rate to 60hz, has that been changed?
HiDPI. It's somewhat unusual for a top end laptop to have 1920x1080 screens these days, and Wayland doesn't support 4k very well. You can upscale, but it looks like garbage, or it has a 2x mode, which draws image and such slightly too large, or you can deal with everything being tiny. For gaming, the latency is bad and always on vsync is horrible. They've fixed the 60Hz lock though, fortunately. This only applies to…
So there is no way for a game to bypass wayland and write directly to the fullscreen framebuffer? You're just stuck with an extra frame or two of latency?
As for the people complaining about Wayland possibly missing some of X's features, remember that it takes time for something to mature, to accrete features and fixes, and Wayland hasn't had that time yet. If we give it the time and support it could and almost definitely will grow into something even better than X. We can't stay on X forever without incurring even worse results on ourselves than what we'll get when we switch to Wayland.
And another thing. For the people who complain about Wayland in the same breath as PulseAudio and SystemD: this tells is much more about you than about these projects. The only thing Wayland has in common with the other two is that it's new, and that you don't like it. It's more modular and more UNIXy and more open than X, arguably.
Earlier quoted context omitted.
My concern at the moment with Wayland (and Systemd, Pulseaudio, DBus and a few others) is that Linux is loosing modularity. All these dependencies seem to be getting more or less mandatory. Running a distribution without them is getting harder. Given that they are all getting pushed by the same group of people at Red Hat, it is concerning as they are effectively gaining control of the Linux userland. And given that t…
>they are effectively gaining control of the Linux userland. but they aren't gaining control by some dastardly power grab, they're gaining control because they're the only ones actually putting in the work. They're simply doing what they think is best for their product, while at the same time contributing their work back to the open source world. That is good, that's how it's supposed to work. The only reason they're…
The decisions they're making are what prevents others from doing that. When they make a bad choice you would be willing to write code to correct, you can no longer just replace that one component with one that works better, because everything is tightly coupled without clean interfaces between them.
Then since no one else can justify spending the resources to replace the entire Linux userland in order to correct that one problem, the problem remains, and they accumulate. And still no one else can do anything about it unless they have the resources to replace far more than the individual problematic component(s).
Earlier quoted context omitted.
I grepped wlroots for "nvidia" and got no hits.
https://github.com/swaywm/sway/blob/9670ccee683ab985e89eb043...
Earlier quoted context omitted.
Where do we even begin? Windows managers? Consistent window decorations? Thousands of applications? Consistent performance? Redshift? Global keybindings?
> Windows managers? 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…
> 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...
Sway has become one of my favorite pieces of software. The only issue is that Sway or Wayland seems to have trouble implementing an easy to use redshift/nightlight. Based on my research into eye strain and talking to my optometrist I keep redshift on 24/7 and I can’t go back.
Redshift works with this patch: https://github.com/jonls/redshift/pull/663
I would use Wayland, but the most actively-developed tiling window manager, sway, doesn't work with the NVIDIA graphics card I own. And come to think of it, isn't that a really weird problem to have? On X, the compositor (responsible for actually drawing all the windows on the screen) and the window manager (responsible for deciding how to arrange the windows and what their title bars/borders should look like) can be…
Actually the opposite is true.
Recently everyone is converging on re-using the same compositor library, written by among others sway’s author: wlroots.