Re: Raising windows on Wayland
I started a thread on wayland-devel, lets do follow ups there. David
Re: Raising windows on Wayland
On 07/05/2018 07:19 PM, David Edmundson wrote: > X11 startup system is also used for notifying the UI, via taskbar or > whatever else about the application starting up before it maps a surface. It's definitely something we want to still have in the UI (we've broken it on X11 in the past and it's made users sad and file bugs). So even if it's out of scope for this particular protocol, eventually we want to have one. I think Gnome has a proprietary one. > David Cheers, Eike
Re: Raising windows on Wayland
On Tue, Jul 3, 2018 at 7:45 PM, Martin Flöser wrote: > Am 2018-07-03 18:58, schrieb David Edmundson: > >> >>> >> Ideally this needs to be standardized so that it does not only work >>> with our applications but with any. >>> >> >> Even within just KDE apps, we have code like QDesktopServices spawning >> links in code we can't manipulate. Anything non standard, simply isn't >> worth merging. >> >> But I don't think standardising anything would be too hard. >> >> Effectively we want something like xdg-foreign which exists. The >> difference is that it lasts temporarily and it's not manipulating >> parents. >> > > xdg-foreign is pretty much the "token" idea :-) > > Cool, I think we're on the same page. I'll take it up. > >> There are two interesting questions: >> >> Do we want/need to support wayland window sending activating an >> xwayland window? >> > > short term: yes, long term: no. Ideally would be a mapping to the startup > notifications used on X11. > > >> Would we need a serial of the user event (xdg_popup style)? It would >> which kinda matches the X event timestamps? >> It's trickier as you'd need a protocol to generate a UUID for both >> that and the surface to sidechannel, but it's not impossible. >> > > I don't think that the serial is needed as the compositor would only pass > on focus if the app which generated the token has currently the focus. > Given that the serial does not provide any additional advantage. And I > don't like just using the serial as that could be guessed. > > Just to clarify a point. I didn't mean just using the serial as a token. If it was needed I meant clients would need to pass seat + serial as args along with the surface to our get_token_from_server request. but I also didn't think it was useful. > if the app which generated the token has currently the focus We might need to tweak that. kickoff will close and lose focus when you click on an app before that app is launched. This will probably be something up to the compositor, rather than something we need to worry about in the spec. --- X11 startup system is also used for notifying the UI, via taskbar or whatever else about the application starting up before it maps a surface. Is that something we want to bring in? (IMHO no) David
Re: Raising windows on Wayland
Am 2018-07-03 18:58, schrieb David Edmundson: Ideally this needs to be standardized so that it does not only work with our applications but with any. Even within just KDE apps, we have code like QDesktopServices spawning links in code we can't manipulate. Anything non standard, simply isn't worth merging. But I don't think standardising anything would be too hard. Effectively we want something like xdg-foreign which exists. The difference is that it lasts temporarily and it's not manipulating parents. xdg-foreign is pretty much the "token" idea :-) There are two interesting questions: Do we want/need to support wayland window sending activating an xwayland window? short term: yes, long term: no. Ideally would be a mapping to the startup notifications used on X11. Would we need a serial of the user event (xdg_popup style)? It would which kinda matches the X event timestamps? It's trickier as you'd need a protocol to generate a UUID for both that and the surface to sidechannel, but it's not impossible. I don't think that the serial is needed as the compositor would only pass on focus if the app which generated the token has currently the focus. Given that the serial does not provide any additional advantage. And I don't like just using the serial as that could be guessed. --- The other potential solution that I was wondering about, that's waaay simpler, definitely waaay crappier, but possibly simple enough to just work without really having issues. Could client A just release focus (somehow) when spawning an app? If nothing has focus and toplevel B appears, it seems sensible that kwin would focus it. Won't work for the "discover already running" usecase. Cheers Martin
Re: Raising windows on Wayland
> > Ideally this needs to be standardized so that it does not only work with > our applications but with any. > Even within just KDE apps, we have code like QDesktopServices spawning links in code we can't manipulate. Anything non standard, simply isn't worth merging. But I don't think standardising anything would be too hard. Effectively we want something like xdg-foreign which exists. The difference is that it lasts temporarily and it's not manipulating parents. There are two interesting questions: Do we want/need to support wayland window sending activating an xwayland window? Would we need a serial of the user event (xdg_popup style)? It would which kinda matches the X event timestamps? It's trickier as you'd need a protocol to generate a UUID for both that and the surface to sidechannel, but it's not impossible. --- The other potential solution that I was wondering about, that's waaay simpler, definitely waaay crappier, but possibly simple enough to just work without really having issues. Could client A just release focus (somehow) when spawning an app? If nothing has focus and toplevel B appears, it seems sensible that kwin would focus it.
Re: Raising windows on Wayland
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
Re: Raising windows on Wayland
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. Aleix
Re: Raising windows on Wayland
The token approach sounds good. I also like the idea of generalizing it to cover startup notifications and pursuing standardization for it. Cheers, Eike
Re: Raising windows on Wayland
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
Re: Raising windows on Wayland
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. Aleix
Re: Raising windows on Wayland
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
