[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Thank you Bruce for posting this. Yes, I fancied reading it, and I find it kinda contradictional.
If you do not have a coordinate system you can point to, you still MUST have some way of telling the window manager where (about) you wish it to show something up and how.
Maybe there is an indirect way like telling it "please show this window in 33% of the current screen size somewhere in the center". Otherwise, wayland would only be able to serve frameless windows in whole-screen-mode, like on mobiles or - as he put it - on car screens. But it runs on normal screens with windows with all widgets, so how is it achieved?
On a printed page, you usually count mm and the printer system will translate this into pixels for its individual wand. There must be such a way in Wayland too - and Pekka does mention a translation layer for older applications. It's just a shame they seem to realize this only now. 

Regards
Rolf


Am 29.04.24 um 14:50 schrieb Bruce Steers:

I got this reply on the wayland developers list if anyone fancies a read....

---------- Forwarded message ---------
From: *Pekka Paalanen* <pekka.paalanen@xxxxxxxxxxxxx <mailto:pekka.paalanen@xxxxxxxxxxxxx>> 
Date: Mon, 29 Apr 2024 at 13:43
Subject: Wayland design principles (Re: wayland and gambas)
To: Bruce Steers <bsteers4@xxxxxxxxx <mailto:bsteers4@xxxxxxxxx>>, <wayland-devel@xxxxxxxxxxxxxxxxxxxxx <mailto:wayland-devel@xxxxxxxxxxxxxxxxxxxxx>> 


On Sat, 27 Apr 2024 08:28:00 +0100
Bruce Steers <bsteers4@xxxxxxxxx <mailto: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 <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
Follow-Ups:
Re: Fwd: Wayland design principles (Re: wayland and gambas)Jussi Lahtinen <jussi.lahtinen@xxxxxxxxx>
References:
Fwd: Wayland design principles (Re: wayland and gambas)Bruce Steers <bsteers4@xxxxxxxxx>