Discussion
Many wayland problems can never be "fixed" because they are not "problems", they are fundamental to the very definition of what Wayland is and form the foundational UX philosophy of several compositors - and that's a problem.
I've been using some variation of desktop linux has my main OS for decades, I've been building a wayland compositor and thinking about migrating my setup to the future.
Some problems I can mitigate through extensions, others are only solvable through schism.
Having now spent a a significant part of the last couple of years exploring the internals of wayland, and understanding the history of the decisions that were made and why, I've become very aware of how much of the public discussion and overall perception of wayland neglects the above context.
I am making my peace with the idea that I have applications that only run well on my compositor but I don't think it's a particularly healthy indication for the future cohesiveness of desktop Linux.
@sarahjamielewis I often get the feeling that we have failed to tackle the problem of handling paradigm concordances.
Okay, fancy wording so some examples:
- web sites not being easily available in multiple equivalent forms: desktop, mobile, text only, no JavaScript, accessibility friendly, etc.
- ditto desktop applications, adding in CLI use
I seem to recall claims that multi-paradigm is meant to be part of the philosophy of Wayland, but usually only hear of it as a desktop technology.
> I seem to recall claims that multi-paradigm is meant to be part of the philosophy of Wayland, but usually only hear of it as a desktop technology.
These two points are closely related. Wayland was designed with multi-paradigm in mind and in doing so ensured that many desktop conventions couldn't be ported to it (or could be but with great debate and tribulation)
Resulting in much discourse regarding wayland on the desktop (and very little about e.g. it's wide in-vehicle use)
@sarahjamielewis can you expand on that? I'm not particularly well-informed about wayland beyond that it's the new thing and that screen sharing used to be a problem because IIRC KDE and GNOME did it differently. I'm curious to hear the perspective of somebody more in the weeds ^^
Sure.
Screen sharing is a good example, it's a problem that can be solved through a protocol extension; the main challenge is getting everyone to agree on one. There is no one at the heart of wayland who is philosophically against the idea of screen sharing.
Contrast with the idea that windows should be able to determine their size/position. This idea violates a core wayland tenet. The closest extension is ext_zones which is unlikely to ever be implemented by certain compositors.
@sarahjamielewis@mastodon.social @dequbed@mastodon.chaosfield.at I'm guessing they want windows to know as little about their environment as possible but "size/position" that sounds like it could complicate things?
Windows can know their size in wayland, and there are mechanisms to request a certain size - but the compositor always has final determination (which has some knock on consequences for things like menu positioning)
Global position is never given to clients. Even ext-zones gets around this by having the position be zone-relative (with one of the major discussion contentions being that compositors are most likely to make zone = output and thus expose global position to clients)
I have a suite of applications I've written over many years that rely on the ability to automatically resize and position windows.
I could technically rewrite the application to do everything in one window (a lot of work), or implement ext_zones in a compatible way in my compositor (less work, but now my apps will only work on compositors that share the same zone semantics) - hence "schism".
@sarahjamielewis i assume this is for stuff like tool windows? I'm surprised that enabling stuff like that isn't core wayland functionality with how many applications use that pattern ^^'
And in my case window positioning is the key hangup, but it is far from the only example of something expected by certain sets of users/developers but not compatible with wayland philosophy
Another: wayland as spec'd leaves decorations up to the client so in order to be compatible with wayland applications a compositor can never enforce server window side decorations - GTK4 has taken this to it's logical conclusion putting core functionality into what was previously decoration.
Install bonfire.cafe
Get the full app experience
