On 10 July 2018 6:03:26 pm AEST, David Edmundson
wrote:
>>Hm. If you wanted to, you could make this explicit by requiring an
>event serial in the export_surface request rather than the wl_surface.
>
>Certainly an option. Though I'm not sure we have a use case of needing
>to limit a client
>Hm. If you wanted to, you could make this explicit by requiring an event
>serial in the export_surface request rather than the wl_surface.
Certainly an option. Though I'm not sure we have a use case of needing
to limit a client releasing its focus?
>Does this interface need to exist?
It
On Thu, Jul 5, 2018 at 4:56 PM, Drew DeVault 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
On 2018/7月/05 04:26, David Edmundson wrote:
> This protocol is to address the following use case.
>
> A user clicks on a URL link in an IRC chat and a web browser opens. We want
> an existing browser window to raise or if it's a newly spawned application
> to claim focus on startup.
>
>
I'm not sure why an activiation request has to jump through these
surface export hoops first. We export a surface... to do what with it?
Export it to whom? What do they do with it? Instead, we could just
activate the surface (though I'd suggest activating an xdg_toplevel
rather than an arbitrary
This protocol is to address the following use case.
A user clicks on a URL link in an IRC chat and a web browser opens. We want
an existing browser window to raise or if it's a newly spawned application
to claim focus on startup.
Naturally we also don't want any arbitrary client to be able to
