I've seen it happen so many times, and I've done it. It's the very same principle that leads to almost every construction project running behind schedule — a man simply underestimates the complexity of nigh every task he endeavors to complete.
Sometimes, software patches and new features get tacked on and tacked on and the system loses all semblance of cohesion or integrity. Thinking of the system as a whole, iterating with the confidence brought by tests of some sort, one can begin to detangle all the unncessary intermixing and duplicate work and begin to make the system sensible.
but I've taken several projects in the 100s of k-lines and translated them into projects with equivalent functionality and spanning between 1-2 decimal orders of magnitude less source code.
that's not an argument for rewriting in all circumstances - I just think at least half of most mature software is just 'junk dna' - useless boilerplate, unused paths, poor abstractions, etc
It can be very frustrating to modify low quality and ugly code so I feel much better after a rewrite.
If the requirements stay exactly the same, then yeah, there’s no point.
And then they had to include more of what they cast away because they underestimated the number of consumers of things they personally weren't using.
libinput originally actually did not have a way to disable and configure pointer acceleration I believe because the developed thought there was no reason to ever turn it off. He was not a gamer and was largely ignorant of how essential being able to disable it is for the level of accuracy required for video games.
At this point Wine is still at the point of not considering a Wayland port until some severe changes happen at all — it cannot even begin to map the WinAPI to Wayland as it could to X11 at this point because too many features they need are missing that the developers didn't consider would be necessary for many things that Windows simply exposes.
https://bugs.winehq.org/show_bug.cgi?id=42284#c1
It's from 2017 but it details some of the features that they would need which Wayland does not consider to support.
I'm also not convinced there is _nothing_ the wine devs could do to resolve this. They already suggested some ways to deal with the lack of APIs but they refuse to implement them more on principal rather than practical issues.
In the end, if only Wine is using xwayland, thats not a particularly bad position to be in and Wayland seems to work well for native linux applications.
Absolutely not. This is needed for many things, and that you think it can simply be stripped shows your lack of appreciation of the needs of many other users and software.
How will you without this for instance make:
- a notification daemon that creates a notification bubble at some part of the screen - a toolbar of some sorts that sits at a specific place on the screen and is summoned on command - a collapsible terminal application that summons itself on a certain global hotkey and otherwise lays hidden - any such application that summons itself - a program that rearranges other windows for any particular purpose such as tiling them in a specific way that the user wants
All these things obviously exist as of this moment, and are used by many users, and can't be made to work on Wayland because the developers were “correct” according to you in their assumption that none might ever need this.
> I'm also not convinced there is _nothing_ the wine devs could do to resolve this. They already suggested some ways to deal with the lack of APIs but they refuse to implement them more on principal rather than practical issues.
Your conviction would be wrong; I've been in the same situation and talked to the Wayland developers and it is they who refuse to implement various features that are highly requæsted based on principle.
> In the end, if only Wine is using xwayland, thats not a particularly bad position to be in and Wayland seems to work well for native linux applications.
Yes, if it would be only Wine, perhaps, but it's not only Wine — and that you think it's only Wine shows either having never researched the mountain of issues, or willfully ignoring them because these concerns are immediately encountered when researching the issue of developers of many an application who are not pleased that their application fundamentally can't work on Wayland because it endeavored to not include basic functionality that every other display protocol has.
These were not “mistakes” — the reason everything from Windows, to X11, to Quartz has these features is because users need them for what they wish to do.
And this is only about programs choosing the positions of their own windows. A simple, trivial other thing is every time a new Hearthstone expansion comes out and I buy about 80 new packs with in-game currency that I game insists that I sit through the animations of opening them which bores me. I refuse and rather simply minimize the Hearthstone window and even though it doesn't have focus rapidly send it endless spacebar key events with a trivial xdotool command which then does this in about 15 minutes without needing my attention — such a simple thing cannot be done in Wayland at the moment and most likely never will because “users should not be able to simulate key events” as far as the Wayland developers are concerned, which is obviously a function with many use cases.
“Users should not be able to ...” was the mantra of the Wayland developers when they started, and in many cases they have relented and allowed them because they realized they severely underestimated for how many things users do need to do that.
The DE comes with one, you just send your notification to it. Apps creating their own notification bubbles is an anti feature and should be prevented if possible. They don't show in the notification box/ on the lock screen and ignore your do not disturb setting.
>a toolbar of some sorts that sits at a specific place on the screen and is summoned on command
Put the toolbar inside the app window or make it a new window and let the user decide where it goes. Apps being able to draw over the screen should probably be provided as a root feature as it is pretty dangerous left exposed.
>a collapsible terminal application that summons itself on a certain global hotkey and otherwise lays hidden
I just checked and gnome allows launching programs via shortcuts. An app should not be able to passively sit in the background collecting keystrokes to launch itself. This is a massive security risk
>a program that rearranges other windows for any particular purpose such as tiling them in a specific way that the user wants
The window manager implements wayland and is free to arrange windows however it wants as it is a trusted component.
Basically all of the stuff in your comment is achievable via the DE/WM. Its a good thing that programs no longer have free reign to do whatever they want and passively record the users keyboard, screen and draw over anything.
And what if you don't like the one the compositor comes with and want to use a different one?
Pantheon, XFCE, Mate and many other systems by design run their notification daemon as a separate process that can be disabled so that the user may choose what he wishes; there are also many standalone notification daemons to fill this gap.
> Put the toolbar inside the app window or make it a new window and let the user decide where it goes. Apps being able to draw over the screen should probably be provided as a root feature as it is pretty dangerous left exposed.
I mean a global toolbar at the bottom or top of the screen.
> I just checked and gnome allows launching programs via shortcuts. An app should not be able to passively sit in the background collecting keystrokes to launch itself. This is a massive security risk
It's a “security risk” of a far lesser magnitude than “an application can read and write all data owned by your user”.
It's silly to remove features because processes that run with your user's rights have the ability to fuck you up. Might we remove the rm utility now because it's a security risk that it can unlink files?
> The window manager implements wayland and is free to arrange windows however it wants as it is a trusted component.
And what if it not do so as the user wishes to and the user wishes to use something else to do it?
This is why X11 eventually evolved the EWMH standard to allow the window manager and a third program to coöperate without conflict on this.
> Basically all of the stuff in your comment is achievable via the DE/WM. Its a good thing that programs no longer have free reign to do whatever they want and passively record the users keyboard, screen and draw over anything.
Everything is achievable if it be built in to the compositor including fully fledged video games and web browsers.
The reason we have such a thing as software is because the compositor won't have all those things we want, and if it did for every single user, then it would be so bloated beyond belief.
The Wayland solution to missing features is “the compositor should do it”, but no compositor has all these features; that is why software exists, and that is why one often writes one's own software.
The difference is that on X11 since it's part of the standard it will work everywhere, rather than only with one window manager.
But Wayland developers did think of additional requirements but were thinking that ad hoc inventing something that may or may not be implemented downstream would be a bad idea (it is), so they created a standard way of adding extensions to the base protocol - which are created with cooperation between major desktop environments - the actual implementers of said protocols.
And as of now, wayland is pretty feature-compatible with x, in an actually extendable way (much more close to the UNIX philosophy if that’s your thing).