[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic