Xpra: Ticket #2242: Tray icons/indicators too small in GNOME 3

I was trying to get https://pastebin.com/u9TWcJ9b

Any clue what might be interfering with the tray here?



Sun, 31 Mar 2019 23:25:36 GMT - Alex Guzman: attachment set

xpra 2.5 ebuild


Sun, 31 Mar 2019 23:27:50 GMT - Alex Guzman:

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)


Mon, 01 Apr 2019 03:19:39 GMT - Antoine Martin: owner changed; milestone set

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)


Mon, 01 Apr 2019 03:40:06 GMT - Alex Guzman:

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

Also, I am using topicons-plus.


Mon, 01 Apr 2019 03:40:38 GMT - Alex Guzman: attachment set

pidgin icons directly (one indicator + tray icon)


Mon, 01 Apr 2019 03:41:05 GMT - Alex Guzman: attachment set

pidgin with xpra (no appindicator python bindings)


Mon, 01 Apr 2019 03:41:26 GMT - Alex Guzman: attachment set

pidgin with xpra and libappindicator python bindings


Tue, 02 Apr 2019 08:53:57 GMT - Antoine Martin:

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?


Tue, 02 Apr 2019 22:26:55 GMT - Alex Guzman: attachment set

list of files installed by xpra-2.5 ebuild


Tue, 02 Apr 2019 22:29:48 GMT - Alex Guzman:

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.


Tue, 02 Apr 2019 22:55:34 GMT - Alex Guzman:

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.


Tue, 02 Apr 2019 22:56:24 GMT - Alex Guzman: attachment set

Tray icons using latest SVN build


Tue, 02 Apr 2019 22:57:10 GMT - Alex Guzman: attachment set

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


Tue, 02 Apr 2019 22:57:39 GMT - Alex Guzman: attachment set

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


Tue, 02 Apr 2019 22:59:01 GMT - Alex Guzman:

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.


Wed, 03 Apr 2019 14:08:27 GMT - Antoine Martin:

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)


Thu, 04 Apr 2019 02:56:39 GMT - Alex Guzman: attachment set

dumped status/tray icons


Thu, 04 Apr 2019 02:57:05 GMT - Alex Guzman: attachment set

xpra start -d tray output


Thu, 04 Apr 2019 02:57:28 GMT - Alex Guzman: attachment set

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


Thu, 04 Apr 2019 02:58:06 GMT - Alex Guzman:

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


Thu, 04 Apr 2019 03:48:33 GMT - Antoine Martin: attachment set

add warnings on all tray configure handlers


Thu, 04 Apr 2019 03:49:57 GMT - Antoine Martin:

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:


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


Thu, 04 Apr 2019 04:08:19 GMT - Alex Guzman:

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.


Thu, 04 Apr 2019 04:08:53 GMT - Alex Guzman: attachment set

xpra server log with warn patch


Thu, 04 Apr 2019 04:09:13 GMT - Alex Guzman: attachment set

xpra client log with warn patch


Thu, 04 Apr 2019 04:39:26 GMT - Antoine Martin: attachment set

force reinit


Thu, 04 Apr 2019 04:40:41 GMT - Antoine Martin:

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 wiki/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.


Thu, 04 Apr 2019 05:22:22 GMT - Alex Guzman:

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.


Thu, 04 Apr 2019 05:26:10 GMT - Antoine Martin:

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.


Thu, 04 Apr 2019 06:28:41 GMT - Alex Guzman:

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.


Thu, 04 Apr 2019 07:00:57 GMT - Antoine Martin:

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.


Thu, 04 Apr 2019 09:07:16 GMT - Alex Guzman:

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.


Thu, 04 Apr 2019 09:07:44 GMT - Alex Guzman: attachment set

server logs during right click repro


Thu, 04 Apr 2019 09:08:02 GMT - Alex Guzman: attachment set

client logs during right click repro


Wed, 03 Jul 2019 16:37:46 GMT - Antoine Martin:

Python/GTK2 Linux Gentoo 2.6 n/a wayland client version 3.0-r22306 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.


Mon, 22 Jul 2019 16:11:41 GMT - Antoine Martin:

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 ticket:2161#comment:3.

A better solution for gnome-shell would be ticket: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..)


Wed, 07 Aug 2019 08:50:04 GMT - Antoine Martin: status changed; resolution set


Sat, 23 Jan 2021 05:45:59 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2242