Tray icons/indicators too small in GNOME 3

[totaam]

Issue migrated from trac ticket # 2242

component: android | priority: major | resolution: needinfo | keywords: tray,hidpi

2019-04-01 00:24:21: reanimus created the issue

---

I was trying to get https://github.com/kaueraal/run_scaled working with pidgin to run it scaled with my HiDPI system. The main window works fine, but I've noticed that the tray icons and indicators are too small and don't respond to input. I ran xpra start --start-child=pidgin --exit-with-children, then ran xpra attach -d tray. The output is at https://pastebin.com/u9TWcJ9b

Any clue what might be interfering with the tray here?

[totaam]

2019-04-01 00:25:37: reanimus uploaded file xpra-2.5.ebuild (4.0 KiB)

xpra 2.5 ebuild

[totaam]

2019-04-01 00:27:50: reanimus commented

---

Also, forgot to mention, I'm running Gentoo with linux 4.20.10-gentoo, GNOME/gnome-shell 3.30.2, and xpra 2.5 (ebuild attached here in case it helps)

[totaam]

2019-04-01 04:19:40: antoine commented

---

reanimus: can you attach a screenshot of the tray icon?

Are you using the topicons-plus extension? Does it work any better with appindicator instead? (no idea what gentoo package provides that)

[totaam]

2019-04-01 04:40:06: reanimus commented

---

Ran with libappindicator installed with python bindings: https://pastebin.com/pAm1MyFq

Also, I am using topicons-plus.

[totaam]

2019-04-01 04:40:39: reanimus uploaded file pidgin-no-xpra.png (14.1 KiB)

pidgin icons directly (one indicator + tray icon)

[totaam]

2019-04-01 04:41:05: reanimus uploaded file pidgin-xpra.png (2.3 KiB)

pidgin with xpra (no appindicator python bindings)

[totaam]

2019-04-01 04:41:27: reanimus uploaded file pidgin-xpra-indicator.png (9.2 KiB)

pidgin with xpra and libappindicator python bindings

[totaam]

2019-04-02 09:53:57: antoine commented

---

First, in your log I see:

Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/util.py", line 191, in make_instance
    v = c(*args)
  File "/usr/lib64/python2.7/site-packages/xpra/platform/xposix/appindicator_tray.py", line 51, in __init__
    self.tray_widget = Indicator(self.tooltip, filename, APPLICATION_STATUS)
TypeError: App.Indicator.__init__() argument 2 must be string, not None

So somehow xpra failed to find its default icon.
I'm not sure why that is, but since you're using gentoo, maybe the package is not fully installed, installed in the wrong place, or just missing some bits.
r22258 will make it try to continue anyway, so you can try appindicator instead of topicons.
You could also try the python3 build, maybe that will fare better.

The problem with the icon size is because topicons is giving us a bogus tray icon size:

GTKStatusIconTray.get_geometry() geometry area rectangle=(0, 0, 200, 200)

When we find those bogus values, we take a guess - this used to be 24x64, as of r22260 we now use 48x48.

Does that help?

[totaam]

2019-04-02 23:26:55: reanimus uploaded file xpra-files.txt (88.4 KiB)

list of files installed by xpra-2.5 ebuild

[totaam]

2019-04-02 23:29:48: reanimus commented

---

I attached the list of files installed by xpra... I'm not sure why it wouldn't be able to find the icon when it can find it for the other tray implementations.

I'll give the latest code a shot and see if that improves it.

[totaam]

2019-04-02 23:55:35: reanimus commented

---

Ran the latest.

With python appindicator support, the xpra indicator works wonderfully, but there are no tray icons or indicators for pidgin.

Without appindicator support, the main xpra tray icon is working correctly, but the tray icon + indicator for pidgin still show up as tiny icons.

[totaam]

2019-04-02 23:56:24: reanimus uploaded file xpra-latest.png (2.8 KiB)

Tray icons using latest SVN build

[totaam]

2019-04-02 23:57:10: reanimus uploaded file latest-indicator.txt (11.5 KiB)

output of xpra attach -d tray with latest SVN code and appindicator support

[totaam]

2019-04-02 23:57:40: reanimus uploaded file latest-noappindicator.txt (55.7 KiB)

output of xpra attach -d tray with latest SVN code without appindicator support

[totaam]

2019-04-02 23:59:02: reanimus commented

---

Also worth mentioning, right clicking the forwarded tray icons doesn't seem to work. The log without appindicator support includes some messages emitted when trying to right click in the tray.

[totaam]

2019-04-03 15:08:27: antoine commented

---

list of files installed by xpra-2.5 ebuild
The icons are in /usr/share/xpra/icons as expected.
Unfortunately there is no debug logging we can use to figure out why that still failed.

I'm not sure why it wouldn't be able to find the icon when it can find it for the other tray implementations.
Could well be because appindicator is a complete mess of an API, you have to give it the icon as a name, without a file extension, so we have some really convoluted code to try to do that.

With python appindicator support, the xpra indicator works wonderfully, but there are no tray icons or indicators for pidgin.
r22280 should fix that by not using appindicator for forwarding system trays, only for xpra's own tray. (except we can't use it on Fedora Gnome, because it doesn't show up at all there: r22283 ...)

Without appindicator support, the main xpra tray icon is working correctly, but the tray icon + indicator for pidgin still show up as tiny icons.
I'm not sure why that is.
Looks like this may be calculating the scaling wrong:

set_icon_from_pixbuf(<gtk.gdk.Pixbuf object at 0x7f85282fbcd0 (GdkPixbuf at 0x55b08addac00)>)
    geometry=(3480, 10, 32, 32), icon size=(128, 128)

The icon size is large - we clamp it to 128x128 server side.
The client side is only 32x32.
Why they are not in sync is not clear. Can you get the server's -d tray log output?

Can you also try r22289 or later with:

XPRA_SAVE_SYSTRAY=1 /usr/bin/python2 /usr/bin/xpra attach

It will save all tray updates to PNG files. (both from the systray class handling the screen updates and from the statusicon backend implementation)

[totaam]

2019-04-04 03:56:40: reanimus uploaded file icons.tar.gz (13.0 KiB)

dumped status/tray icons

[totaam]

2019-04-04 03:57:06: reanimus uploaded file xpra-server-tray.log (44.6 KiB)

xpra start -d tray output

[totaam]

2019-04-04 03:57:29: reanimus uploaded file xpra-client-tray.log (36.6 KiB)

xpra attach -d tray output (to accompany server output)

[totaam]

2019-04-04 03:58:07: reanimus commented

---

Just updated to r22296 and uploaded the logs + icons dumped by xpra

[totaam]

2019-04-04 04:48:33: antoine uploaded file tray-reconfigure-debug.patch (2.8 KiB)

add warnings on all tray configure handlers

[totaam]

2019-04-04 04:49:58: antoine commented

---

This is weird, your server log has:

client @02.739 ClientTray(1:Pidgin).reconfigure(True) sending configure for geometry=(3428, 10, 32, 32) : \
    (3428, 10, 32, 32, {'screen': 0, 'encoding.transparency': True, 'encodings.rgb_formats': ['RGBA', 'RGB', 'RGBX'], 'orientation': 'HORIZONTAL'})

But no server-side tray logging after that.
You should be seeing this (taken from my test):

client @10.193 ClientTray(3:test_system_tray_colors.py).reconfigure(True) sending configure for geometry=(1771, 5, 24, 24) ...
tray SystemTrayWindowModel(0x400040) configured to: (1771, 5, 24, 24)
SystemTrayModel.move_resize(1771, 5, 24, 24)

Showing that the server is adjusting the real system tray to the same position and size.
If it doesn't do that, then the tray window remains at its original location and size, from your log that's:

dock_tray: geometry=(200, 200)

Which we clamp to 128x128.

And sure enough, those proportions match the tray icon picture that you uploaded. (roughly 2.5 times smaller in every dimension than it should be).

So:

• r22298 changes the default size we use to 64x64, and you can override it, ie: XPRA_MAX_TRAY_SIZE=48 xpra start ... - this may make things slightly better, but this is more of band-aid than a proper fix
• r22299 tries to force a refresh when we resize the tray - this shouldn't be needed, but was cheap enough to add
• please try the server patch attached (with or without -d tray logging) to see if we get more tray size configuration logging that way.. or if things get lost somewhere: [/attachment/ticket/2242/tray-reconfigure-debug.patch]

---

This should not matter in this case, but who knows... do you use a patched dummy driver or the stock Xorg one on gentoo?

[totaam]

2019-04-04 05:08:20: reanimus commented

---

I don't patch anything for Xorg, so I assume stock?

I ran with the latest, attaching logs. The icons look better now, though not quite the right size yet. Also worth noting: when I reinitialize windows manually via the xpra tray menu, the tray icon becomes the right size.

Still not responding to input when i try to click the icon, though.

[totaam]

2019-04-04 05:08:54: reanimus uploaded file xpra-server-warn-patched.log (62.8 KiB)

xpra server log with warn patch

[totaam]

2019-04-04 05:09:14: reanimus uploaded file xpra-client-warn-patched.log (52.2 KiB)

xpra client log with warn patch

[totaam]

2019-04-04 05:39:26: antoine uploaded file tray-force-send-configure.patch (0.5 KiB)

force reinit

[totaam]

2019-04-04 05:40:41: antoine commented

---

The icons look better now, though not quite the right size yet.
They would probably be (almost?) right if you used XPRA_MAX_TRAY_SIZE=48 or XPRA_MAX_TRAY_SIZE=32.

Also worth noting: when I reinitialize windows manually via the xpra tray menu, the tray icon becomes the right size.
That's very interesting. All we do for trays during "window reinit" is to send a configure packet. Does the new patch help?
(it should achieve the same thing using a timer just one second after the tray is meant to have been shown - giving it sufficient time for things to settle down)

Still not responding to input when i try to click the icon, though.
That could be because of the unpatched dummy driver. See Xdummy. (pointer limits patch?)
Works fine here.
Or it could just be caused by topicons. Gnome's refusal to support system trays properly is bewildering.

[totaam]

2019-04-04 06:22:23: reanimus commented

---

XPRA_MAX_TRAY_SIZE=48 seems to do it about right. I patched my xdummy driver and now I can get it to respond to clicks if I click in the right spot (I think that one is a topicons bug -- it applies to the xpra tray icon and the non-forwarded pidgin icon as well). However, it's still not responding to right clicks.

[totaam]

2019-04-04 06:26:10: antoine commented

---

Did the other patch fix things without needing to set XPRA_MAX_TRAY_SIZE?

However, it's still not responding to right clicks.
That's unlikely to be an xpra bug.

[totaam]

2019-04-04 07:28:42: reanimus commented

---

Did the other patch fix things without needing to set XPRA_MAX_TRAY_SIZE?

It was incorrect for a bit but eventually settled, yeah.

That's unlikely to be an xpra bug.

Any clue where I might begin looking? The right click works fine for local apps, it's only for the forwarded pidgin that it fails to register the right click.

[totaam]

2019-04-04 08:00:57: antoine commented

---

It was incorrect for a bit but eventually settled, yeah.
Thanks, merged in r22304.

Any clue where I might begin looking? The right click works fine for local apps, it's only for the forwarded pidgin that it fails to register the right click.
Maybe it is an xpra bug. Does it occur with win32 clients?

Can you post the server log, with both client and server running with -d tray of just when you right click?

IIRC, the StatusIcon implementation only gives us a single signal for a right click, we then have to emulate both a button press and a release. To do that, we have to get the position of the pointer accurately, and hope that the actual system tray is where we think it is - otherwise we end up clicking on empty space, or worse another window.

[totaam]

2019-04-04 10:07:17: reanimus commented

---

It may be something along those lines? When I was attempting to repro, I was seeing the tray icon cause clicks to register within the main pidgin window (specifically, clicking on the account menu). Not sure what was causing that one, but I imagine it may be related.

Beyond that, I managed to get it to log. The log has a couple of left clicks in it -- this was to verify it was a spot that receives regular left clicks successfully, and the last client logged event is the right click.

The forwarded tray, on top of not accepting right clicks, also is very particular about where it accepts input. The topicons plugin already has some sort of bug that makes it so clicks only register on the top and bottom of the icon (not the center), so I have to click along the top edge. With the forwarded pidgin icon, there's an even smaller spot of that upper edge that registers clicks. The difference when compared to local icons (i.e. non-forwarded pidgin or the xpra tray) is quite noticable.

[totaam]

2019-04-04 10:07:45: reanimus uploaded file xpra-server-rightclick2.log (51.0 KiB)

server logs during right click repro

[totaam]

2019-04-04 10:08:02: reanimus uploaded file xpra-client-rightclick2.log (41.7 KiB)

client logs during right click repro

[totaam]

2019-07-03 17:37:47: antoine commented

---

Python/GTK2 Linux Gentoo 2.6 n/a wayland client version 3.0-[r22306](../commit/741384df604e2205eaed726195a1aec0ec1736b1) 64-bit
Hmm. Maybe wayland is not helping?

Initially, we don't get a valid geometry for the tray icon:

2019-04-04 02:01:57,868 client @01.321 GTKStatusIconTray.get_geometry() geometry area rectangle=(0, 0, 200, 200)

So we send this: ClientTray(1:Pidgin).reconfigure(False) sending configure for geometry=(0, 0, 48, 48) ....
We eventually get dimensions that are more correct (48x48) but the position is still wrong (0,0):

ClientTray(1:Pidgin).reconfigure(True) sending configure for geometry=(0, 0, 48, 48) : ...)

And eventually the position is adjusted too:

2019-04-04 02:01:58,879 client @02.332 GTKStatusIconTray.get_geometry() geometry area rectangle=(3526, 6, 40, 40)

And the click events do seem to land where the tray is mapped:

2019-04-04 02:02:02,493 client @05.947 button_packet=['button-action', 1, 1, 1, (3541, 12), []]

But then the position changes again:

2019-04-04 02:02:02,498 client @05.951 GTKStatusIconTray.get_geometry() geometry area rectangle=(3576, 6, 40, 40)

Yet we don't end up sending a configure packet to the server.. Or maybe this is a different tray icon? xpra's own tray icon perhaps? Maybe running the client with --tray=no would clarify that.

Then the icon updates come through as 48x48 image data, which is strange since we have configured the tray window as 40x40:

2019-04-04 02:02:03,409 client @06.862 set_tray_icon() using unique RGBA icon: 48x48 (has-alpha=True)
2019-04-04 02:02:03,411 client @06.864 tray icon scaled to 40x40

Can you please grab xpra info of when clicks are not working, together with the client's -d tray log. Then we should be able to see if the position is correct and if the clicks should land in the right place.

[totaam]

2019-07-22 17:11:42: antoine commented

---

Without being able to reproduce this myself, and without the -d tray log, I will have to close this as NEEDINFO.
As per previous comments, please check with win32 client and/or x11 client so we know which side has a problem.

For some "fun" related Linux desktop tray complete failure (API senseless breakage), see #2161#comment:3.

A better solution for gnome-shell would be #476#comment:12 (yay, more desktop specific code that's going to be deprecated and replaced by something else before we have a chance to implement it..)