Wayland design principles (Re: wayland and gambas)

Thiago Macieira thiago at kde.org
Mon Apr 29 19:53:19 UTC 2024

On Monday 29 April 2024 10:05:32 GMT-7 Bruce Steers wrote:
> 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.

Please describe the need you have, not the means by which you think you can 
solve the need. For example, why do you think you need to specify absolute 
positioning for certain windows?

The Wayland philosophy on this has been that the compositor knows best where 
to place the windows for regular applications. That does not include fixed 
desktop components, such as the task bar or desktop wallpapers, but those need 
to communicate directly with the compositor they are a desktop for.

Someone may have said they had a need to grab the keyboard and obtain key 
events even when the window wasn't focused. But why is that? X11 uses 
keyboard-grabbing to implement dismissal of popup menus, something that 
Wayland solved properly instead. Another use-case was to ensure that focus 
couldn't be stolen while typing a password... again, Wayland can solve that by 
the window describing itself as "I'm recording a password" so the compositor 
can implement a higher focus-stealing threshold or other attention-grabbing 
techniques (how many of us have typed passwords in the wrong window?).

Other things are done for security: you can't inject events into other 
windows, so we lose the auto-type feature in KeyPassXC. You can't perform 
arbitrary screengrabs any more, but instead screensharing applications must 
ask the compositor to let the user choose which window(s) to share.

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

More information about the wayland-devel mailing list