[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Raising windows on Wayland
From:       Martin_Flöser <mgraesslin () kde ! org>
Date:       2018-07-03 16:32:46
Message-ID: 825ed380c9af1ad7111527a0f5b6a2eb () kde ! org
[Download RAW message or body]

Am 2018-07-03 18:05, schrieb Aleix Pol:
> On Tue, Jul 3, 2018 at 6:02 PM Martin Flöser <mgraesslin@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
[prev in list] [next in list] [prev in thread] [next in thread]