Am 2018-07-03 18:41, schrieb Aleix Pol:
On Tue, Jul 3, 2018 at 6:32 PM Martin Flöser <mgraess...@kde.org>
wrote:
Am 2018-07-03 18:05, schrieb Aleix Pol:
> On Tue, Jul 3, 2018 at 6:02 PM Martin Flöser <mgraess...@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
