Raising windows on Wayland

[Martin Flöser]

Am 2018-07-03 18:41, schrieb Aleix Pol:
> On Tue, Jul 3, 2018 at 6:32 PM Martin Flöser <mgraesslin at kde.org> 
> wrote:
>> 
>> Am 2018-07-03 18:05, schrieb Aleix Pol:
>> > On Tue, Jul 3, 2018 at 6:02 PM Martin Flöser <mgraesslin at kde.org>
>> > wrote:
>> >>
>> >> Am 2018-07-03 14:45, schrieb Aleix Pol:
>> >> > Dear kwiners,
>> >> > Would it be possible to find a way to do so?
>> >> >
>> >> > I know we don't want windows to be positioning themselves willy-nilly
>> >> > on the window stack, but we certainly need to figure out his use-case.
>> >> >
>> >> > What would need to happen to do this?
>> >> >
>> >> > If you need to, I can compile a list of use-cases.
>> >>
>> >> Hi Alex,
>> >>
>> >> this really depends on the use case. Instead of allowing general
>> >> raising
>> >> I would prefer to make the workflows work correctly. E.g. if you want
>> >> that the polkit authentication dialog is above discover we can make
>> >> this
>> >> work right now without needing to implement window raising.
>> >>
>> >> Cheers
>> >> Martin
>> >
>> > That's not the use-case.
>> >
>> > A use-case is I was using Discover, someone pressed
>> > appstream://org.kde.kate and wants to install it. Discover changes but
>> > doesn't go into the foreground.
>> > Similarly, we want the web browser to raise after we've pressed a URL
>> > on an app.
>> > Another thing I keep hitting: I open telegram or konversation on
>> > krunner, nothing happens. It's because it's open somewhere under my
>> > current window.
>> 
>> Ok, that's all the same pattern: we have an action in application A
>> which should activate (and raise) application B.
>> 
>> First of: KWin should prevent application B to activate. This is only
>> working because we don't have focus stealing prevention for Wayland
>> windows yet. If we had focus stealing prevention, it would kick in and
>> prevent application B from activating.
>> 
>> The solution to this is a mechanism to pass activation around through 
>> a
>> side channel. Application A would need to create a token before
>> activating B and pass the token to B. B would use this token towards 
>> the
>> compositor and the compositor would be able to allow the request as it
>> sees that application A passed the focus to application B. That kind 
>> of
>> matches what startup notifications used to be on X11. This is 
>> basically
>> https://phabricator.kde.org/T4448
>> 
>> Ideally this needs to be standardized so that it does not only work 
>> with
>> our applications but with any.
>> 
>> Cheers
>> Martin
> 
> I'm not sure how viable this is though. xdg-open doesn't know who's
> the caller, and so doesn't just calling "konversation" from bash.

xdg-open could get the token through side channel and pass it on just 
like any other application.

Calling konversation from bash is a corner case which is also not 
supported on X11 (KWin needs the startup notification and that's only 
generated by KLauncher, not from bash).

Cheers
Martin