wibox.widget.systray: missing application icons

[Jajauma]

The oddball problem I came across lately is that inherent systray widget doesn't show some application icons (transmission-gtk, pasystray) while others (nm-applet, keepassx) are shown just fine. Here is a screenshot with interrogation marks I put where applications icons are supposed to be drawn. The empty areas are clickable with mouse, producing respective application menus or other actions.

Compare with an external implementation of the systray protocol (http://stalonetray.sourceforge.net/), all four applications icons are sheer working.

I wonder if the issue could be connected to our incurring icon frenzy #908 somehow.

[blueyed]

Is this on master?
pasystray and others work for me.

But I've also seen a missing icon once in a while lately.

[Jajauma]

Yes, it is git master at 441587a on the pictures.

[psychon]

Could you gather some information about the missing icons?

Start with xwininfo -tree and click on the wibox. This should list the "Awesome systray window" and its children. Show the output of this. For each direct child of this window (especially for the missing icons) I'd be interested in the output of xwininfo -id 0x42 and xprop -id 0x42 where 0x42 is the ID that you got in the previous step.

[Jajauma]

OK, this is what it looks like and here is the gist.

https://gist.github.com/Jajauma/0bde81381a8169f86bd62267103e7b82

[Jajauma]

Apparently the number of systray applications and their launch order does matter. If I kill nm-applet, the tray is redrawn and transmission icon with a gear handle is left lonely sitting in the shrinked systray as if nothing had happened.

[psychon]

Thanks. I can't spot any difference between them and the values that I was interested in (Map State: IsViewable and _XEMBED_INFO = 0x1, 0x1) both look good.
However, I noticed that for transmission (which seems to be the missing icon), the size is below its minimum size. Width/Height is 21, WM_NORMAL_HINTS specifies a minimum size of 24x24.

Could you try making you wibox larger (e.g. by adding height = 30 as an argument to awful.wibar / awful.wibox) and see if the icon appears?
If this helps, I guess that the problem is outside of awesome and GTK just does not draw the tray icon if its too small (and btw: how on earth can a tray honor these size hints? We don't magically get more space just because some tray icon asks for it?!?).

Edit: I looked at stalone tray. They also ignore size hints if KLUDGE_USE_ICONS_HINTS is disabled in the settings. I think that this is the default. So apparently, no, this cannot be due to size hints... :-(

[Jajauma]

Sure thing the taller wibox didn't make any difference. Still no transmission icon while nm-applet icon is present.

[psychon]

Then I'm out of ideas. This always means to try the sledgehammer: Could you run awesome and transmission under xtrace (also known as x11trace; http://xtrace.alioth.debian.org/) and get me the resulting trace files?
If the problem is reproducible in Xephyr, you can do something like the following:

Xephyr :1
xtrace --relative-timestamps --outfile /tmp/output.txt --nocopyauthentication --display :1 --fakedisplay :2 &
sleep 1
export DISPLAY=:2
transmission-gtk &
nm-applet &

It would be best if you do as few things to Xephyr as possible. If the above is enough at reproducing the problem, please kill Xephyr somehow instead of shutting down awesome, transmission-gtk and nm-applet properly. This should produce a smaller log file.
(I'd ask for leaving nm-applet out, but apparently this is necessary for reproducing the problem....)

Thanks

[Jajauma]

All right, I managed somehow to pull that xtrace thing off. Indeed the problem is reproducible under Xephyr, nm-applet is not needed. There are 1500 lines or so of the real harsh logfile and a Xephyr screenshot with interrogation mark as before. I tried not to touch anything inside Xephyr before killing it.

https://gist.github.com/Jajauma/51f63d8358fed1316690430251d974ad

[psychon]

Sigh... I don't know.

So in line 275 GTK starts identifying the systray. Systray window is 0x00200008. It then starts setting up its going-to-be systray icon in line 308. This is window 0x0060003. In line 349 it asks the system tray "hey, I have a new icon for you" and awesome reacts (e.g. line 353: The tray icon is reparented into the system tray).
Apparently awesome then updates the wibox and starting from line 382, the systray icon and the systray itself are given the right size and are made visible.

In line 388, the X11 server tells transmission/GTK "the user can now see your window" and line 389 is an Expose event (="Please draw this window").
The reaction to this is not to draw the icon. Instead, the main window of transmission is created, made visible and drawn to!?!?

Around line 568, GTK does some things to the tray icon (like querying its size and children (why would it have children????)).

In line 646 it tries to resize the tray icon to size 24x24 (awesome will ignore this request).
Then, for 66 seconds nothing happens and in line 1483, GTK is informed that the system tray icon is no longer in the tray (apparently you closed awesome and thus the system tray was shut down?). It reacts by cleaning up after the tray icon and closing it.

So... why would GTK ignore the expose event that tells it to redraw the icon?

As a (very cheap) work-around, you could mess with the systray's background color to force a redraw of the icon. For example, the following should do:

-- Add somewhere globally and use this in your wibox, so that we get a reference to the systray
local my_systray_icon = wibox.widget.systray()

local orig_bg = beautiful.bg_systray
function force_systray_redraw()
    beautiful.bg_systray = "#ff0000" -- Assuming this is not the actual BG color of your systray
    my_systray:emit_signal("widget::redraw_needed")
    gears.timer.start_new(0.5, function()
        beautiful.bg_systray = orig_bg
        my_systray:emit_signal("widget::redraw_needed")
    end)
end

[Jajauma]

Oh, that was a great breakdown. Unfortunately your workaround didn't help. I bound force_systray_redraw using awful.key() and when I press the key the systray blinks red for a half of a second ... and shows still no transmission icon but empty room.

Under the circumstances I can guess my GTK (3.14.13 from CentOS 7) is deadly broken in some way or another (e.g. violates some X11 protocol).

Edit: I tried running tint2 right ontop of AwesomeWM and it was able to handle all my tray application icons without a hitch, like stalonetray earlier.

[Jajauma]

Good news here, I happen to randomly pick the version back from 2015 which works for me. Bisecting says 4daa6e8 is the first bad commit. It was meant to fix some tray icon scaling bug (#487) but I guess it did us something wicked as well.

[psychon]

Good idea. Thanks a lot!

In line 646 it tries to resize the tray icon to size 24x24 (awesome will ignore this request).

So... yeah.

Could you test the following patch? It should/might tell GTK that its resize request was ignored.

diff --git a/event.c b/event.c
index c4e2ea3..58ea414 100644
--- a/event.c
+++ b/event.c
@@ -404,6 +404,24 @@ event_handle_configurerequest(xcb_configure_request_event_t *ev)
         /* Ignore this so that systray icons cannot resize themselves.
          * We decide their size!
          */
+        /* Anyway, send back a synthetic configure notify to let them known the
+         * resize was ignored. Does any spec say anything about this? (EDIT: Xembed says "the embedder acts like a WM to the embedded window, see ICCCM"; so... yup!)
+         */
+        /* ..... :-( */
+        xcb_get_geometry_reply_t *geom = xcb_get_geometry_reply(globalconf.connection,
+                xcb_get_geometry_unchecked(globalconf.connection, ev->window),
+                NULL);
+        if (geom)
+        {
+            area_t area;
+            area.x = geom->x;
+            area.y = geom->y;
+            area.width = geom->width;
+            area.height = geom->height;
+
+            xwindow_configure(ev->window, area, 0);
+        }
+        p_delete(&geom);
     }
     else
         event_handle_configurerequest_configure_window(ev);

Also, why does nm-applet work, but transmission-gtk does not? Are both of them using GTK3 or is one GTK2 and the other GTK3?

[Jajauma]

Certainly your patch did the trick and all of my bitty icons are back now triggering fierce joy ^__^ albeit I'm not sure about that Steam thing from #487 whether it going to like it or not since I don't ever use it. I didn't do a test run that thorough to comprehend every possible graphical toolkit either. Right now all my GTK3 (nm-applet, transmission-gtk, caja, pasystray, pnmixer, firefox + firetray), GTK2 (seamonkey + firetray) and Qt4 (keepassx) application icons are confirmed to display correctly with the patch.

Also, why does nm-applet work, but transmission-gtk does not? Are both of them using GTK3 or is one GTK2 and the other GTK3?

Absolutely no idea, all applications from the OP (being broken or not) use GTK 3.14.13 except keepassx which uses Qt4.

[psychon]

I came up with an even better patch (sending the correct x/y position to the tray icon) and submitted a pull request: #990
@Jajauma Could you also test that patch? I don't expect any surprises, but it's better to be safe than sorry.

[Jajauma]

I fetched and tested the code from #990 and I can confirm it works just as good as original patch from #986 (comment) does on my system. Looking forward to it getting merged.

[psychon]

Thanks!