I was trying to get https://pastebin.com/u9TWcJ9b
Any clue what might be interfering with the tray here?
xpra 2.5 ebuild
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)
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)
Ran with libappindicator installed with python bindings: https://pastebin.com/pAm1MyFq
Also, I am using topicons-plus.
pidgin icons directly (one indicator + tray icon)
pidgin with xpra (no appindicator python bindings)
pidgin with xpra and libappindicator python bindings
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?
list of files installed by xpra-2.5 ebuild
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.
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.
Tray icons using latest SVN build
output of xpra attach -d tray with latest SVN code and appindicator support
output of xpra attach -d tray with latest SVN code without appindicator support
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.
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)
dumped status/tray icons
xpra start -d tray output
xpra attach -d tray output (to accompany server output)
Just updated to r22296 and uploaded the logs + icons dumped by xpra
add warnings on all tray configure handlers
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:
XPRA_MAX_TRAY_SIZE=48 xpra start ...
- this may make things slightly better, but this is more of band-aid than a proper fix
-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?
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.
xpra server log with warn patch
xpra client log with warn patch
force reinit
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.
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.
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.
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.
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.
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.
server logs during right click repro
client logs during right click repro
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.
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..)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2242