xpra icon
Bug tracker and wiki

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#685 closed defect (fixed)

icon forwarding using pixel data does not work

Reported by: Antoine Martin Owned by: alas
Priority: major Milestone: 0.15
Component: server Version: trunk
Keywords: Cc:

Description

I never noticed because on Linux, using the icon name is enough to get the right icon most of the time.
On Windows however, you end up with the default window icon, which is the GTK icon, r7687 at least uses our icon instead.

I've tested v0.7.x and as far back as v0.1.x! None of them get the icon data...

Change History (13)

comment:1 Changed 6 years ago by Antoine Martin

I think it must have been broken by a fedora system update, because I see code dealing with icons, specifically:

  • "png_window_icons" which is present in the initial 0.0.7.x branch
  • moving the icon data to a dedicated packet with the "raw_window_icons" capability: r2033 done for v0.8.x

Here's a patch which makes it obvious with a Linux client, by not setting the window class (which is usually enough for most window managers to find a non-default icon to use):

--- src/xpra/client/client_window_base.py	(revision 7671)
+++ src/xpra/client/client_window_base.py	(working copy)
@@ -111,7 +111,7 @@
             metadata["window-type"] = window_type
 
         self._metadata.update(metadata)
-        if not self.is_realized():
+        if False and not self.is_realized():
             self.set_wmclass(*self._metadata.strlistget("class-instance",
                                                  ("xpra", "Xpra")))
         self.set_metadata(metadata)

comment:2 Changed 6 years ago by Antoine Martin

Milestone: 0.15
Owner: changed from Antoine Martin to Antoine Martin
Priority: criticalmajor
Status: newassigned

Never mind, I had tested wrong, works ok with those two test apps:

It is just that most applications just rely on named icons from the local theme instead. And maybe we should handle this better: if the client doesn't have an icon by that name, we could send the pixels for the icon we find on the server.

Will backport the default icon fix, but lowering the priority for the rest.
I think the windows build is missing a theme or icons.
On Windows the list of icons is empty whereas this is what I get on Linux

import gtk
x=gtk.IconTheme()
print(x.list_contexts())
('International', 'Places', 'Emotes', 'FileSystems', 'Applications', 'Devices', 'Actions', 'Categories', 'Animations', 'MimeTypes', 'Stock', 'Status', 'Emblems')
print(len(x.list_icons()))
404
Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:3 Changed 6 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

OK, I've implemented a workaround in r7697 so that clients without the full list of icons (mostly win32 and osx, but also Linux clients which do not have the same application installed) will now receive the default icon from the server.
Done like this:

  • clients now send the list of icons they know about
  • when we don't have a window icon to send to the client, we look for the "wm_class" against that list and if it isn't in it, we send the icon that we have from the current theme

More could be done in this area I guess, like dealing with the themes, etc. But this will do for now.

Note: on osx, I can't see the window icon anywhere. Maybe we should tell the server not to bother at all in this case?
afarr: Ideas on the OSX window icons? Are they shown anywhere at all? Brief testing? (I used baobab for testing: it was missing its window icon with win32 clients prior to this change)

comment:4 Changed 6 years ago by Antoine Martin

Actually ended up doing more work on this as I found some problems in this area:

  • r7707 gtk3 compat fix
  • r7760 + r7761: add a default window icon for shadow servers, r7779 makes it work in all cases (wm-class undocumented weird behaviour)
  • r7763: old bug
  • r7764: support for dynamic window icon updates, with test in r7762: test_window_icon_colors: press any key to stop / start the window icon updates
  • r7781 allows the client to specify the icon size it wants, and we now use the icon logger for easier debugging (-d icon)

afarr: please see comment:3, we want to know how big the icons should be on various platforms (in particular osx and win32), at the moment the size is hardcoded at 64x64. I think OSX may be showing them when using "expose" mode? Or does it use the dock icon?

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:5 Changed 6 years ago by alas

Testing with 0.15.0 r7847 windows client (windows 7) ... I no longer see the active application icon for Xpra showing as a GTK icon (doubt that's the point of the ticket, but not entirely sure).

Launching baobab, gedit, test_window_icon_colors, or firefox... the window icons seem to be displaying as expected (scrolling over the active application Xpra icon, the Xpra application sub windows are showing icons that seem to match those in the windows themselves, which I suspect is the point of the ticket, but again, not entirely sure).

The win32 icons I'm seeing all seem to be sized as I'd expect, not sure that other sizes would make sense.

I'll confer further with Smo to see if I'm looking at the right things, and then I'll test further with OSX (and re-test with windows if necessary).

comment:6 Changed 6 years ago by alas

Owner: changed from alas to Antoine Martin

Well, consesnus seems to be that I am looking in the right place, so it looks like icons are being forwarded successfully in windows (I presume there was no native windows 7 icon for gedit, for instance).

Meanwhile, testing with a 0.15.0 r7897 client (OSX 10.9) vs. 0.15.0 r7897 server (Fedora 20):

  • I see a generic executable icon in dock (in place of an Xpra icon). Meanwhile, gedit shows no icon whatsoever, neitherwise google-chrome, baobab, firefox, nor calibre (no idea where they “ought” to go… except maybe in top-right menu, whatever that might be called… though safari doesn’t have an icon there when run locally, so it seems to be “optional” enough that it might not be worth the effort…)

Looks like an Xpra icon in the dock for OSX and the icon forwarding ought to look as expected with OSX as well.

comment:7 Changed 6 years ago by Antoine Martin

Status: newassigned

I see a generic executable icon in dock (in place of an Xpra icon)


That's a new bug. Not sure when this broke (not sure it is actually related to the the work in this ticket). Taking the ticket back.

comment:8 Changed 6 years ago by Antoine Martin

So... the win32 DPI fix for #697 somehow broke the tray icon for OSX!

That's because we create an import cycle, with too many places trying to initialize the gui code early, and in the end it doesn't initialize at all.
Fixed in r7899, with further loop prevention in r7900.

Please confirm and close - unless I've broken something else in the process..

comment:9 Changed 6 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

(forgot to re-assign for testing)
afarr: just close this ticket unless you have tray icon problems on osx with 0.15.

comment:10 Changed 6 years ago by alas

Resolution: fixed
Status: newclosed

I don't really see any icons being forwarded on osx - except the Xpra icon in the dock, which is looking as expected.

Closing.

comment:11 Changed 6 years ago by Antoine Martin

@afarr: you need to run an application that uses the tray to see it forwarded, either apps like vlc or one of the tray test applications in our test tree.

comment:12 Changed 6 years ago by alas

Tried to test with test_window_icon_from_files.py... but the window that the script created was empty and non-responsive.

Downloaded and installed vlc and played an avi file... no change of icon in the dock (still only Xpra icon). The application itself displays the vlc cone icon between videos... is that all that we're expecting with osx?

comment:13 Changed 6 years ago by Antoine Martin

Sorry about that, I was getting confused in comment:11.

The osx feature that seems to show the window icons is Mission Control formerly known as Exposé.

I can get some sort of overview on my 10.5.x VM using F8 and F10, but no window icons.
Lowering the priority (and not re-opening the ticket either) - it probably uses the dock icon if you manage to get a view showing icons at all (which I cannot).

Note: See TracTickets for help on using tickets.