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.

@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 ^^

@dequbed

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 @dequbed 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?

@Tengu @dequbed

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)

@sarahjamielewis @dequbed What's the reasoning for not giving global position to clients?

@Tengu @dequbed

To maximize support for different ui paradigms without complicating the protocol e.g. if the compositor wants to render the window as a rotating cube, or in 5 different places then the compositor can do so without having to define some complex protocol to inform the client of where is might be.

To put another way: in Wayland the idea of clients having a global unique "position" isn't assumed to be a meaningful statement.

Sign in to participate in the conversation
Mauvestodon

Escape ship from centralized social media run by Mauve.