From kde-panel-devel Tue Jul 03 16:51:26 2018 From: =?UTF-8?Q?Martin_Fl=C3=B6ser?= Date: Tue, 03 Jul 2018 16:51:26 +0000 To: kde-panel-devel Subject: Re: Raising windows on Wayland Message-Id: <16b2f8fead09b2ba037f053c382bfe2f () kde ! org> X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=153063669306155 Am 2018-07-03 18:41, schrieb Aleix Pol: > On Tue, Jul 3, 2018 at 6:32 PM Martin Flöser > wrote: >> >> Am 2018-07-03 18:05, schrieb Aleix Pol: >> > On Tue, Jul 3, 2018 at 6:02 PM Martin Flöser >> > 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