Attachment 8864 Details for Bug 17592 – IRC logs, chat with GTK+ developers

IRC logs, chat with GTK+ developers

xembed-sni-proxy-vs-gtk3.txt (text/plain), 6.83 KB, created by Samuel Verschelde on 2017-01-16 18:57:24 CET

(hide)

Description:

Filename:

MIME Type:

Creator: Samuel Verschelde

Created: 2017-01-16 18:57:24 CET

Size: 6.83 KB

patch

obsolete

>18:05 < stormi> Hi. I'm a packager/bug triager in the Mageia distro and we have a very annoying bug about GTK+3 applications whose systray icon can't be interacted with in KDE's Plasma 5 desktop. Including our own tools, GTK+3 based. This is because those applications don't use the new StatusNotifierItem specification, but in theory it should still work because Plasma has a xembed/SNI proxy, and it does work for GTK+2 applications. But not with GTK+3, for some reason. See this comment of mine that summarizes what we know: https://bugs.mageia.org/show_bug.cgi?id=17592#c46
>18:05 < stormi> I'm looking for some help both for:
>18:06 < stormi> 1) Establishing where the bug comes from in the case of GTK+3 applications
>18:06 < stormi> 2) Try to port our own applications to using StatusNotifierItem, but I don't know what's the recommended way.
>18:07 < stormi> Can you help with any of those?
>18:11 <@ebassi> stormi: Nothing has changed in the GtkStatusIcon implementation in a *very* long time
>18:11 <@ebassi> stormi: And I'm also pretty sure it's the same implementation we use in GTK+ 2.24
>18:12 <@ebassi> stormi: But it should be easy to diff between gtk-2-24 and gtk-3-22
>18:14 < stormi> I'll checkout the code.
>18:15 <~Company> i know there are various differences between GTK2 and GTK3
>18:15 <~Company> due to how xembed is very much like 1985 X11 code
>18:15 <~Company> and we got rid of colormaps etc
>18:17 <@ebassi> Mainly styling and using icon helper
>18:17 <@ebassi> But the logic is pretty much the same
>18:17 <@ebassi> stormi: Maybe you'll have to be a bit more precise; what does "can't be interacted" mean?
>18:17 <@ebassi> No pointer events?
>18:18 < stormi> ebassi: right or left click doesn't make any action, and no information when hovering it
>18:18 < stormi> ebassi: it's specific to Plasma and its xembed-sni-proxy that makes the bridge between SNI and XEmbed
>18:19 <@ebassi> https://paste.fedoraproject.org/528390/14845869/ â this is the diff, btw
>18:19 <@ebassi> stormi: Do status icons work with other system trays, like gnome-panel/mate-panel, or gnome-shell?
>18:19 < stormi> and unfortunately I can't make the xembed-sni-proxy dev dig deeper into it (well, I haven't tried direct email for now but that's in last resort)
>18:19 <~Company> it's more likely to involve GDK and its input handling than the status icon
>18:20 < stormi> ebassi: yes
>18:20 <~Company> stormi: does starting the status icon process with GDK_CORE_DEVICE_EVENTS=1 make it work?
>18:20 <@ebassi> Oh, XInput
>18:21 <@ebassi> Right, because Qt doesn't really believe in XInput2 :-)
>18:21 < stormi> Company: it does!
>18:21 <~Company> stormi: now you've got a problem
>18:22 < stormi> :(
>18:22 <@ebassi> Indeed
>18:23 <~Company> stormi: it means it's somewhere in gdk-x11's input stack
>18:23 <~Company> stormi: maybe garnacho can save you?
>18:23  * stormi prays hard
>18:25 <@ebassi> Except he's on vacation, AFAIR :-)
>18:25 <@ebassi> Could an issue with selecting the event mask on the embedding process
>18:25 < garnacho> one thing I don't get, GtkPlug relies on receiving pointer events from its own window, according to its own mask, this implies something is sending crafted pointer events to the status icon
>18:26 < garnacho> ebassi: just back today :)
>18:27 < stormi> garnacho: not sure I understand but it might be xembed-sni-proxy that does that?
>18:27 < stormi> Plasma's proxy to translated XEmbed to SNI and vice-versa
>18:28 <@ebassi> "Activate and context menu events are replyed via X send event into the embedded container as left and right clicks"
>18:28 <@ebassi> ttps://github.com/KDE/plasma-workspace/tree/master/xembed-sni-proxy
>18:29 < garnacho> there you go :)
>18:31 < garnacho> so xembed-sni-proxy sends events gtk3 doesn't listen to anymore by default, and the status icon is left unable to receive those events it actually listens to (xi2)
>18:32 < stormi> what are the events gtk3 doesn't listen to by default?
>18:32 < garnacho> XButtonPress/Release, the ones defined in X[lib].h
>18:33 <@ebassi> xcb_send_event(c, false, m_windowId, XCB_EVENT_MASK_BUTTON_PRESS, (char *) event);
>18:33 < stormi> and that's why it works with GDK_CORE_DEVICE_EVENTS=1 because then it does listen to them?
>18:33 <@ebassi> stormi: Yep
>18:34 <@ebassi> Basically, if you disable anything that happened in X11 input for the past 15 years, you can get them to work
>18:34 < stormi> so xembed-sni-proxy definitely needs to be fixed
>18:36 < garnacho> stormi: yes, there's little gtk+ can do, at least without a bunch of (mis)assumptions
>18:36 < stormi> but is there a way to send events that will work both in gtk2 and gtk3, or a way to handle them separately?
>18:37 <@ebassi> stormi: Ideally, you should not send input events at all
>18:37 <@ebassi> And let the toolkit consume what it wants
>18:38 < stormi> yes, that's the proper solution but it implies porting every app to SNI
>18:38 <@ebassi> What's SNI?
>18:38 < stormi> since Plasma will not listen to anything else
>18:38 < garnacho> what ebassi says would be the best fix indeed. If it's not possible, they could alternatively send both, the embedded window still specifies the event mask
>18:38 < stormi> ebassi: https://freedesktop.org/wiki/Specifications/StatusNotifierItem/
>18:38 <@ebassi> stormi: I fail to see how's that connected
>18:38 <@ebassi> The embedded window should be receiving X events already
>18:39 <@ebassi> Instead of interposing an X window and doing a proxy
>18:39 <@ebassi> But, then again, I know nothing of the Plasma architecture
>18:40 < stormi> Plasma doesn't support systray integration via XEmbed, so by default GTK applications are missing from the systray, except when they comply with the StatusNotifierItem specification (using libappindicator for example).
>18:40 < stormi> But then they realized it was a bit of a strong decision
>18:41 <@ebassi> AFAIR, libappindicator is still an XEMBED client
>18:41 <@ebassi> It's just the DBus API that's different
>18:41 < stormi> so they did that: http://blog.davidedmundson.co.uk/blog/xembed_back
>18:41 < stormi> yes, maybe I don't use the proper terms
>18:42 < stormi> so now we have this kind of proxy that allows those applications to be back in the systray (sort of)
>18:42 <@ebassi> Oh, well
>18:42 < stormi> and that's what doesn't interact well with gtk3
>18:42 < stormi> and now thanks to you I know why
>18:42 <@ebassi> stormi: Right. The interposition is what's breaking. The XEMBED/tray icon spec does not consider the idea of a proxy
>18:43 < stormi> Maintaining a distro can be such a nightmare :)
>18:43 <@ebassi> The whole thing assumes the embedded window receives input events
>18:43 <@ebassi> It was also written before we had XInput2
>18:43 <@ebassi> stormi: Well, there's a reason why we are trying to drop tray icons ;-)
>18:44 < stormi> don't make me afraid too early
>18:45 < stormi> I like the idea of sending both events and letting the event mask play
>18:45 < stormi> Can I attach this conversation to bug reports?
>18:45 < garnacho> sure
>18:46 < stormi> thanks a lot

18:05 < stormi> Hi. I'm a packager/bug triager in the Mageia distro and we have a very annoying bug about GTK+3 applications whose systray icon can't be interacted with in KDE's Plasma 5 desktop. Including our own tools, GTK+3 based. This is because those applications don't use the new StatusNotifierItem specification, but in theory it should still work because Plasma has a xembed/SNI proxy, and it does work for GTK+2 applications. But not with GTK+3, for some reason. See this comment of mine that summarizes what we know: https://bugs.mageia.org/show_bug.cgi?id=17592#c46
18:05 < stormi> I'm looking for some help both for:
18:06 < stormi> 1) Establishing where the bug comes from in the case of GTK+3 applications
18:06 < stormi> 2) Try to port our own applications to using StatusNotifierItem, but I don't know what's the recommended way.
18:07 < stormi> Can you help with any of those?
18:11 <@ebassi> stormi: Nothing has changed in the GtkStatusIcon implementation in a *very* long time
18:11 <@ebassi> stormi: And I'm also pretty sure it's the same implementation we use in GTK+ 2.24
18:12 <@ebassi> stormi: But it should be easy to diff between gtk-2-24 and gtk-3-22
18:14 < stormi> I'll checkout the code.
18:15 <~Company> i know there are various differences between GTK2 and GTK3
18:15 <~Company> due to how xembed is very much like 1985 X11 code
18:15 <~Company> and we got rid of colormaps etc
18:17 <@ebassi> Mainly styling and using icon helper
18:17 <@ebassi> But the logic is pretty much the same
18:17 <@ebassi> stormi: Maybe you'll have to be a bit more precise; what does "can't be interacted" mean?
18:17 <@ebassi> No pointer events?
18:18 < stormi> ebassi: right or left click doesn't make any action, and no information when hovering it
18:18 < stormi> ebassi: it's specific to Plasma and its xembed-sni-proxy that makes the bridge between SNI and XEmbed
18:19 <@ebassi> https://paste.fedoraproject.org/528390/14845869/ â this is the diff, btw
18:19 <@ebassi> stormi: Do status icons work with other system trays, like gnome-panel/mate-panel, or gnome-shell?
18:19 < stormi> and unfortunately I can't make the xembed-sni-proxy dev dig deeper into it (well, I haven't tried direct email for now but that's in last resort)
18:19 <~Company> it's more likely to involve GDK and its input handling than the status icon
18:20 < stormi> ebassi: yes
18:20 <~Company> stormi: does starting the status icon process with GDK_CORE_DEVICE_EVENTS=1 make it work?
18:20 <@ebassi> Oh, XInput
18:21 <@ebassi> Right, because Qt doesn't really believe in XInput2 :-)
18:21 < stormi> Company: it does!
18:21 <~Company> stormi: now you've got a problem
18:22 < stormi> :(
18:22 <@ebassi> Indeed
18:23 <~Company> stormi: it means it's somewhere in gdk-x11's input stack
18:23 <~Company> stormi: maybe garnacho can save you?
18:23  * stormi prays hard
18:25 <@ebassi> Except he's on vacation, AFAIR :-)
18:25 <@ebassi> Could an issue with selecting the event mask on the embedding process
18:25 < garnacho> one thing I don't get, GtkPlug relies on receiving pointer events from its own window, according to its own mask, this implies something is sending crafted pointer events to the status icon
18:26 < garnacho> ebassi: just back today :)
18:27 < stormi> garnacho: not sure I understand but it might be xembed-sni-proxy that does that?
18:27 < stormi> Plasma's proxy to translated XEmbed to SNI and vice-versa
18:28 <@ebassi> "Activate and context menu events are replyed via X send event into the embedded container as left and right clicks"
18:28 <@ebassi> ttps://github.com/KDE/plasma-workspace/tree/master/xembed-sni-proxy
18:29 < garnacho> there you go :)
18:31 < garnacho> so xembed-sni-proxy sends events gtk3 doesn't listen to anymore by default, and the status icon is left unable to receive those events it actually listens to (xi2)
18:32 < stormi> what are the events gtk3 doesn't listen to by default?
18:32 < garnacho> XButtonPress/Release, the ones defined in X[lib].h
18:33 <@ebassi> xcb_send_event(c, false, m_windowId, XCB_EVENT_MASK_BUTTON_PRESS, (char *) event);
18:33 < stormi> and that's why it works with GDK_CORE_DEVICE_EVENTS=1 because then it does listen to them?
18:33 <@ebassi> stormi: Yep
18:34 <@ebassi> Basically, if you disable anything that happened in X11 input for the past 15 years, you can get them to work
18:34 < stormi> so xembed-sni-proxy definitely needs to be fixed
18:36 < garnacho> stormi: yes, there's little gtk+ can do, at least without a bunch of (mis)assumptions
18:36 < stormi> but is there a way to send events that will work both in gtk2 and gtk3, or a way to handle them separately?
18:37 <@ebassi> stormi: Ideally, you should not send input events at all
18:37 <@ebassi> And let the toolkit consume what it wants
18:38 < stormi> yes, that's the proper solution but it implies porting every app to SNI
18:38 <@ebassi> What's SNI?
18:38 < stormi> since Plasma will not listen to anything else
18:38 < garnacho> what ebassi says would be the best fix indeed. If it's not possible, they could alternatively send both, the embedded window still specifies the event mask
18:38 < stormi> ebassi: https://freedesktop.org/wiki/Specifications/StatusNotifierItem/
18:38 <@ebassi> stormi: I fail to see how's that connected
18:38 <@ebassi> The embedded window should be receiving X events already
18:39 <@ebassi> Instead of interposing an X window and doing a proxy
18:39 <@ebassi> But, then again, I know nothing of the Plasma architecture
18:40 < stormi> Plasma doesn't support systray integration via XEmbed, so by default GTK applications are missing from the systray, except when they comply with the StatusNotifierItem specification (using libappindicator for example).
18:40 < stormi> But then they realized it was a bit of a strong decision
18:41 <@ebassi> AFAIR, libappindicator is still an XEMBED client
18:41 <@ebassi> It's just the DBus API that's different
18:41 < stormi> so they did that: http://blog.davidedmundson.co.uk/blog/xembed_back
18:41 < stormi> yes, maybe I don't use the proper terms
18:42 < stormi> so now we have this kind of proxy that allows those applications to be back in the systray (sort of)
18:42 <@ebassi> Oh, well
18:42 < stormi> and that's what doesn't interact well with gtk3
18:42 < stormi> and now thanks to you I know why
18:42 <@ebassi> stormi: Right. The interposition is what's breaking. The XEMBED/tray icon spec does not consider the idea of a proxy
18:43 < stormi> Maintaining a distro can be such a nightmare :)
18:43 <@ebassi> The whole thing assumes the embedded window receives input events
18:43 <@ebassi> It was also written before we had XInput2
18:43 <@ebassi> stormi: Well, there's a reason why we are trying to drop tray icons ;-)
18:44 < stormi> don't make me afraid too early
18:45 < stormi> I like the idea of sending both events and letting the event mask play
18:45 < stormi> Can I attach this conversation to bug reports?
18:45 < garnacho> sure
18:46 < stormi> thanks a lot

Actions: View

Attachments on bug 17592: 8864