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

List:       kde-panel-devel
Subject:    Re: Raising windows on Wayland
From:       Aleix Pol <aleixpol () kde ! org>
Date:       2018-07-03 16:41:27
Message-ID: CACcA1RqB+rrOK6UdqiTiPZ7+AFa687D1yqaa7qi9SFr69_Yb5w () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jul 3, 2018 at 6:32 PM Martin Fl=C3=B6ser <mgraesslin@kde.org> wrot=
e:
>
> Am 2018-07-03 18:05, schrieb Aleix Pol:
> > On Tue, Jul 3, 2018 at 6:02 PM Martin Fl=C3=B6ser <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-nill=
y
> >> > on the window stack, but we certainly need to figure out his use-cas=
e.
> >> >
> >> > 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.

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