Wayland design principles (Re: wayland and gambas)

[Thiago Macieira]

On Monday 29 April 2024 14:38:10 GMT-7 Bruce Steers wrote:
> Some have no issue like my text editor for example, a standard looking
> editor with window and title bar.
> 
> Although gambas provides a Settings.Write(window_name) /
> Settings.Read(window_name) that saves/restores the window placement and
> size. It's bearable Wayland does not handle this.

Indeed. I don't see the need for most applications to attempt to remember 
their last position. They'll often get it wrong, like opening on the monitor 
I'm not looking at (this annoyed me a lot in X).

Quite frankly, the majority of applications that thought they knew better, 
didn't.

> Other applications I have made include a customizable LCD clock that runs
> at startup and places itself "where I want it"
>
> And a program called Desktop-ish that shows .desktop file folders I can
> customize/add and has many features like customizable menus I have added
> many many things to that are very useful to me.
>
> This also places itself "where I want it"

Both of those sound like like a compositor / window manager feature, not in-
application. The compositor knows the full extent of the display and what else 
is there. For example, if you placed the window on the top-right corner of 
your display, but later enlarged to another monitor, the compositor would know 
whether to move there or not, possibly depending on some characteristics of 
the monitor that was connected (is it a monitor, a TV or a projector?)

By moving this functionality into the compositor / window manager, it can also 
be done for other applications that didn't think to code it. For example, a 
developer may want to always have a terminal on the bottom half of the screen 
or the left half or something, or a web browser window opened on their chat 
website. Or a system monitor application always overlaid on top.

Yes, this would remove some functionality for those users who don't use a 
compositor with those features.

> My Linux is very personalized and works very well for my needs. (It's
> awesome 😎)

Have you tried choosing a better compositor?

> The same could probably be said for many gambas coders.

And of Wayland developers too, as well as a good chunk of all UI developers on 
Linux. I'm not either, actually: I develop a non-graphical library. And I have 
a very customised desktop.

I have a couple of annoyances after the switch to Wayland (for example, 
Firefox can't restore the windows to the virtual desktops they used to be on). 
So I file bugs and requests for improvement where I can't fix things myself. 
There's nothing I've found that would be a *Wayland* showstopper; most of what 
I've found are regular bugs or unimplemented features in the compositor I'm 
using.

The only functionality I've completely lost is KeyPassXC's auto-type feature.

> Now Wayland has come along and seems to be...
> "you can no longer control window placement, deal with it, why even want
> it?, we decided you don't need it"
> 😕
> 
> It is unacceptable for the many who have customized their Linux world with
> their own work.

Are we talking about people who write applications for a single user, 
themselves? That's an incredibly rare type of user and application.

The majority of applications are written for multiple users, who will each 
have different preferences. Compositors are also written for the majority of 
applications, which have little need for absolute positioning. I'm not saying 
there are no use cases: your application and your compositor can have an 
extension that allows them to do something not in the standard Wayland or the 
XDG shell extension. Absolute positioning has been implemented for some 
compositors.

Also, it's not "now". This decision is about 15 years old.

> There is worry in our community that Wayland is going to take over and x11
> will become obsolete.

That's a feature, not a bug. It's the intent. You should also look at the pace 
of development of the implementations: you'll notice that X.org is very much 
in maintenance mode, going on "bug compatibility" mode.

That being the case, you and your community should engage the Wayland 
community and advocate for the features you need given the use-cases you have 
(not the solutions you've had). That community also includes compositor 
developers, some of whom may be more open to further extensions than others. 
For example, kwin_wayland does implement "server-side decorations", a feature 
that other Wayland compositors, including Weston, (IIUC) don't want.

> And because nobody at Wayland seems to care to provide a means of placement
> choice, should you want/need it.

That's factually incorrect.

There are Wayland compositors that implement absolute positioning as an 
extension. They are not mainstream and the extension isn't a standard one, but 
they exist.

> Yes I forgot the screen grabs not being available is a downgrade for us.
> For example simple colour picker routines many of us have don't work now.
> Eg.
> PickedColour = Desktop.Screenshot(Mouse.x, Mouse.y).Image[0, 0]

You *can* still get a screenshot from which to pick a pixel's colour. It just 
involves asking the compositor for it, because we don't want random 
applications doing that without notice.

> It was that simple.

It can still be. Nothing in the protocol or extensions mandates that the above 
change.

>  I hope you understand our dilemma here.

I do not.

I repeat that most of your concerns can be addressed, if you explain the use-
case and the need, not the means by which you've solved that need in the past. 
Not all of them (maybe not even most of them) will be addressed, but you won't 
know until you try.

The Wayland community has been around for over 15 years. I think you should 
have started participating earlier, but better late than never (or when X.org 
stops working and is removed from Linux distributions).

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Principal Engineer - Intel DCAI Cloud Engineering