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

[Jorge Carrión <shordi@xxxxxxxxx>]

Well... X11 for ever, I guess... I just hope that all this doesn't evolve
in the same direction that happened with Ubuntu and gnome 2, when everybody
was happy with all its pretty little things about the cube, the woobly
windows and all that clasic stuff, the bars up and down... that suddenly
became obsolete and "Now Unity, yes or yes"... and gnome 3 saying that "Ah,
ok, but now things are like this yes or yes too... and everyone contributes
their reasons... and nothing is ever the same again. In Spain we have a
saying: "Entre todos la mataron y ella sola se murió", which
translates as: They
all killed her and she died by herself. Nobody is guilty... but she is
died, more or less...

Best regards.

El lun, 29 abr 2024 a las 16:16, Brian G (<brian@xxxxxxxxxxxxxxxx>)
escribió:

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