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