Wayland design principles (Re: wayland and gambas)

[Bruce Steers]

Many thanks for you detailed response Pekka.

Kinda wasn't the answer I was hoping for but the explanation helps a lot
with our understanding.

Seems like a similar situation to when gnome2 became gnome3 and unity and
as popular as It was and adopted by many systems so many people didn't like
it and wanted what they knew that MATE and cinnamon happened and saved the
day. And they are still very popular today.

I guess/hope a similar thing will happen to x11 or Wayland will accept this
particular issue needs addressing and provide a workaround.

As fundamentally Wayland principles are to us, restrictive in a way that I
think many will simply not tolerate.

Respects and thanks again.
Bruce Steers


On Mon, 29 Apr 2024, 13:43 Pekka Paalanen, <pekka.paalanen at haloniitty.fi>
wrote:

> On Sat, 27 Apr 2024 08:28:00 +0100
> Bruce Steers <bsteers4 at gmail.com> wrote:
>
> > Hello
> > I am a gambas basic developer and would like to report some wayland
> > problems. (major issues) that we hear of on the gambas mailing list all
> the
> > time.
> >
> > The attitude towards wayland with gambas coders at present is ,, ditch
> > wayland it sucks, use x11.
> >
> > All gambas users are used to having window X and Y properties to get/set
> > window position and with wayland it is not possible.
> >
> > So any custom home made widgets cannot work as expected.
> > My own desktop has 3 running programs from startup that all have their
> own
> > position set and do not work with wayland as they are borderless (no
> > titlebar) or tray icons and wayland is functionally limited/restrictive.
> >
> > Other things not working with gambas in wayland but okay on X
> >
> > SystemTray icons do not work
> > Form.Sticky (show window on all workspaces) does not work.
> > Form.SkipTaskbar , not working.
> >
> > Like I say due to all these problems our current attitude towards wayland
> > that we have to tell everyone is "get rid of wayland because of the
> > limitations, many things it is lacking"
> >
> > Are there no plans to change any of this?
> > Is waylands attitude towards window positioning just forget it, you are
> no
> > longer in control.
> > Because if yes then it will NEVER be the system of choice (or little
> choice
> > as the case may be) for many of us.
> >
> > Could any wayland developers join the gambas mailing list to possibly
> help
> > us work through some of the issues wayland introduces?
> >
> > gambas is pretty popular and by far the best UI IDE available for
> > freedesktop so please help us work out some of the major problems that
> come
> > with wayland and the wayland limited non-functionality.
> >
> > It would be nice to say "wayland is okay"  but that's not what we are
> > saying at all because wayland just causes many problems. So we say "get
> rid
> > of wayland limited and use X11" and have to explain how restricted
> wayland
> > is for gambas.
>
> Hi Bruce,
>
> I'm sorry, but at least I do not expect the situation to change much
> from the Wayland side. This is a question of fundamental design
> principles being incompatible, especially for the window positioning
> with x,y coordinates topic. The system tray case I am not familiar
> with, so I cannot say anything about that.
>
> I will explain these principles here the best I can, because to my
> knowledge, they still have not been properly documented. Perhaps this
> email could serve as a basis for the Wayland community to document
> them. Sorry for the wall of text, but this for everyone rather than
> just a reply to you. Maybe this explains why the Wayland project seems
> so "stubborn".
>
>
> Wayland's fundamental design principles on the desktop have been
> crystallised to "descriptive, not prescriptive". In other words,
> regular desktop applications are expected to describe their windows
> with enough detail, purpose and intent to let a window system server
> (any of the desktop compositor projects) do the right thing and present
> them the way the end user wants them. This is very much the opposite of
> prescriptive design, where the server does what applications tell it to
> without knowing the intentions or limitations. In other words, in
> Wayland, desktop applications say "here is what I have", not "do as I
> say".
>
> This applies to "regular" desktop applications that are expected to
> work on a very wide range of (desktop) systems, regardless of the
> shape, size, resolution, and number of screens a display system might
> have, or even bringing desktop applications into virtual or augmented
> reality where screens might not even exist.
>
> This might not apply to desktop environment components, and it might
> not apply to non-desktop environments: in-vehicle-entertainment,
> digital signage, set-top boxes, or special equipment displays for
> example. Special programs often use special protocol extensions,
> Wayland or other, to do what they cannot do with just the common set of
> public Wayland interfaces. These special extensions may not be widely
> supported, and they may require special privileges. However, even
> though the Wayland principles may not fully apply, they do make system
> integration easier when they do apply.
>
> The descriptive design principle has allowed a set of protocol
> extensions (xdg) to arise that cater for many kinds of environments
> without actually needing environment-specific extensions. An application
> developed with these principles can work well on a normal desktop, in a
> TV/set-top box, and in a kiosk machine without needing much or any
> tailoring. The kiosk environment makes the active application
> top-level window always fullscreen or maximized, for instance.
>
> As another example, not defining a global coordinate system like X11
> has, has allowed HiDPI display support to be designed in a way that can
> accommodate also mixed-DPI multi-display systems. I believe it would
> have been much harder if not impossible to do if a global coordinate
> system had been defined. For better or worse, this also means there is
> no coordinate system for placing windows, either.
>
> Another related thing is that Wayland attempts to keep applications
> isolated from each by default, for security reasons. It is much easier
> to carefully open access for specific purposes than it is to try to
> secure an open-by-default design. A consequence of this is that
> applications do not know what else is on screen and where, which means
> that applications cannot know everything that could be needed to
> position windows nicely. Only the compositor has the full picture.
>
> These are the main advantages of the Wayland design principles: Desktop
> environments can develop more freely, applications are more widely
> fitting in, and overall policy is where it is (should be) the easiest
> for an end user to customise: in the display server. All in all, more
> power to the window manager (a part of the display server a.k.a
> compositor), which unfortunately also means less power to the
> application developers to decide on the behaviour. The idea is that the
> window manager is in the best position to implement window management
> behaviour the end user wants. End users can pick and choose their DE,
> and they can tune its window management behaviour. Application
> developers can avoid worrying about it, and applications avoid imposing
> window management behaviour that might not always be wanted.
>
> The disadvantage is that the design principles carry a revolutionary
> idea. Roughly nothing worked like this before Wayland. Porting
> to Wayland requires re-designing applications to stop explicitly
> managing their windows, and toolkits have it even worse. I'm sure there
> are still many use cases that just don't work yet, because there is no
> protocol extension to deliver a suitable description.
>
> Yet, somehow Wayland has become popular enough that people are
> increasingly bumping into it, whether they wanted to or not. I doubt we
> would be in this situation if there was no significant merit in
> Wayland's design principles as well. Hence it is very difficult to
> justify letting those principles go. On the other hand, the Linux
> desktop has always been special: it is rare to be able to choose
> between multiple desktop environments on the same operating system.
>
> I recently wrote up
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/194
> in a search for a compromise between Wayland and applications that will
> not be re-designed according to the Wayland principles and would remain
> crippled. The basic idea there is to introduce "legacy compatibility
> extensions" as a stop-gap measure and eventually stop using them for
> those cases where both the application and the toolkits it uses are
> still actively developed. It was met with justified criticism, and it
> was not intended as a future proof solution for any application in the
> first place.
>
> I believe the discussion in that issue is still on-going (it is very
> fresh), and that it would be worth to read through.
>
> Lastly, and I know this is controversial: maybe people should agree to
> disagree? If there is a community that really wants a prescriptive
> window system protocol and wants a more modern approach than X11, then
> maybe they should start on their own thing. It is much more feasible
> today than it was when first thoughts of Wayland appeared. Perhaps
> because of Wayland, the software stacks around Wayland have massively
> developed towards allowing multiple window systems and multiple display
> servers to co-exist. Hardware drivers are no longer tied to a specific
> window system protocol. One would also have Wayland to look at: what
> works and what doesn't. Besides, translating from descriptive to
> prescriptive API is easier than the opposite, so a prescriptive window
> system should have no problems supporting Wayland applications through
> a compatibility layer.
>
>
> Thanks,
> pq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20240429/e47ea295/attachment-0001.htm>