Re: Fwd: Wayland design principles (Re: wayland and gambas)

[Brian G <brian@xxxxxxxxxxxxxxxx>]

I am not sure I completely understand, Did he say basically

Our why or the highway, and not our problem in one single response.

And period, too bad.

On 4/29/24 05:50, Bruce Steers wrote:
> I got this reply on the wayland developers list if anyone fancies a 
> read....
>
> ---------- Forwarded message ---------
> From: *Pekka Paalanen* <pekka.paalanen@xxxxxxxxxxxxx>
> Date: Mon, 29 Apr 2024 at 13:43
> Subject: Wayland design principles (Re: wayland and gambas)
> To: Bruce Steers <bsteers4@xxxxxxxxx>, 
> <wayland-devel@xxxxxxxxxxxxxxxxxxxxx>
>
>
> On Sat, 27 Apr 2024 08:28:00 +0100
> Bruce Steers <bsteers4@xxxxxxxxx> 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

--
~~~~ Brian

Attachment: OpenPGP_0x78BFB26402F48419.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature