[RFC wayland-protocols] unstable: add protocol to give focus to a foreign surface

[David Edmundson]

On Thu, Jul 5, 2018 at 4:56 PM, Drew DeVault <sir at cmpwn.com> wrote:

> I'm not sure why an activiation request has to jump through these
> surface export hoops first.
>

I think it's important to distinguish focus/raising from urgent/needs
attention hints.

I'm only interested in focus/raising.

Historically on X there was a problem of windows claiming focus randomly
and unexpectedly; especially with things like random password prompts when
things loaded. Kwin certainly has an insane amount of focus protection
logic and rules.

If you're not going to give focus to any client that asks, it means you
need some way to separate a client asking for attention and the currently
focused client being ok with it.

I see where you're going with this, though: an atomic and secure way of
> transferring focus to another application. This looks like an attempt to
> express something like intents on Wayland.
>
> I think xdg-portal is becoming the closest thing we have to intents in the
desktop space.

Currently you'll see a "string: window" argument in most the methods which
ties in with the current xdg_foreign.
I basically want that, but I don't always want a parent/child relationship.

>
> Perhaps designing an out-of-band intents system first, then having it
> express some kind of handle, which can then be referred to from Wayland
> for the purpose of securely transferring focus, would be a better
> approach. It's hard to design a good Wayland protocol against the
> ephemeral "it may exist eventually" out-of-band negotiation process.
>

Right, I phrased that very badly.

There is a pre-existing out of band system for X startup notifications that
is defined in the places I said. This exists and is used certainly in
Qt/Kde and GTK code (weirdly gtk wayland also uses desktop_startup_id ...)

X startups are a bit more involved as clients inform the system what exact
process they're starting with atoms for the icon and a name, so the taskbar
can pre-empt things and do startup feedback then pass an ID of this startup
window to the other client.

But ultimately there's a string ID which gets passes between windows out of
band, and kwin on X uses that as a major clue of if a client should get
raised.

Effectively all that needs defining is new variable names.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180705/ed6f4a8d/attachment.html>