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...
I think it must have been broken by a fedora system update, because I see code dealing with icons, specifically:
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)
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
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:
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)
Actually ended up doing more work on this as I found some problems in this area:
-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?
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).
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):
Looks like an Xpra icon in the dock for OSX and the icon forwarding ought to look as expected with OSX as well.
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.
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..
(forgot to re-assign for testing) afarr: just close this ticket unless you have tray icon problems on osx with 0.15.
I don't really see any icons being forwarded on osx - except the Xpra icon in the dock, which is looking as expected.
Closing.
@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.
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?
Sorry about that, I was getting confused in comment:11.
The osx feature that seems to show the window icons is 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).
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/685