GNOME Bugzilla – Bug 658010
Epiphany webapps lose their specific icons when Shell is restarted
Last modified: 2011-09-13 08:34:36 UTC
When you launch an Epiphany web app (using the shiny new web app mode), it uses a dynamically-generated icon in the Dash and the alt-tab switcher which is derived from the content of the page itself - great. But if you then restart Shell (which, if you're running 3.1.4+, you're going to be doing a lot because of https://bugzilla.gnome.org/show_bug.cgi?id=657990 ), the special icon is lost, and the webapp uses the generic 'oh crap this app doesn't have an icon' icon - a sort of low-res take on the terminal icon with a folded corner. This is used in both alt-tab and the Dash.
True! Not sure what I should be doing here for this to work OK, feels like a shell bug?. I guess I'll ask around.
The issue is that the shell seems to expect .desktop files to be in lowercase, somehow. The .desktop file specification says nothing about this, so I guess it's a shell issue.
The core of the issue is that the shell is guessing the desktop file for running applications out of the WM_CLASS property, by lowercasing it and replacing all spaces with dashes (for a WM_CLASS = "Some App", the expected desktop file would be "some-app.desktop"). This might work for 99% of the cases but unfortunately it is not specified in the desktop entry spec. that the files should be restricted to lowercase, dash separated strings.
Created attachment 195901 [details] [review] try harder to find a running app's desktop file Although lowercasing and replacing spaces for dashes might work for most cases, the desktop file spec. says nothing about the desktop files filename format. In case the above guess fails, try to find a .desktop file with the WM_CLASS raw name.
*** Bug 658030 has been marked as a duplicate of this bug. ***
Just spotted another possible failure case for this in my .xsession-errors: (xchat-gnome:2213): EggSMClient-WARNING **: Could not load desktop file '/usr/share/applications/xchat-gnome.desktop': No such file or directory the .desktop file is actually fedora-xchat-gnome.desktop : this is semi-common in Fedora, it's the guideline recommendation when you create an entirely new .desktop file in a package spec, either because upstream's is irredeemably broken or because upstream doesn't ship one. So if it doesn't already, Shell should also try prepending fedora- . (And any analogs that other distros have).
(In reply to comment #6) > Just spotted another possible failure case for this in my .xsession-errors: > > (xchat-gnome:2213): EggSMClient-WARNING **: Could not load desktop file > '/usr/share/applications/xchat-gnome.desktop': No such file or directory > > the .desktop file is actually fedora-xchat-gnome.desktop : this is semi-common > in Fedora, it's the guideline recommendation when you create an entirely new > .desktop file in a package spec, either because upstream's is irredeemably > broken or because upstream doesn't ship one. So if it doesn't already, Shell > should also try prepending fedora- . (And any analogs that other distros have). http://git.gnome.org/browse/gnome-shell/tree/src/shell-app-system.c#n22
ah , someone got there first =)
I need a specific example here of something that's broken. How can I reproduce this?
Like a specific .desktop file name and a specific WM_CLASS.
It's pretty much what's in the bug description, but to make it clear: 1. Create a web application from epiphany (Ctrl+Shift+A), save it as "Some Web App" [ephy will create a Some Web App.desktop file) 2. Launch it [the WMCLASS for the launched app window will be "Some Web App"] 3. Restart the shell [the shell will try to match the WMCLASS to some-web-app.desktop and won't find it, because of (1)]
Why can't epiphany make the WMCLASS some-web-app?
It can, but as I wrote earlier that's not really part of the spec. for desktop entries. I don't really have a strong opinion one way or the other but think that it wouldn't hurt the shell to try to be a bit more robust on this. But it's up to you, I just want this to be fixed.
After discussing this with Colin in IRC, we came to the conclusion that patching the shell to better guess is not going to lead anywhere since there are still many ways in which this can break, so for now we'll just fix ephy. The shell will still need to learn how to handle other active applications whose WM_CLASS won't match that easily the .desktop file but that's out of scope here. Moving back to ephy.
Created attachment 196076 [details] [review] Normalize the web app profile directory and desktop file names This is necessary to allow the shell to guess properly the location of the desktop file out of the WM_CLASS property in the application window. Also, append a sha1 checksum to the filenames to avoid collisions.
Review of attachment 196076 [details] [review]: While we are doing this we should do something to also fix bug #658028
Created attachment 196122 [details] [review] Normalize the web app profile directory and desktop file names This is necessary to allow the shell to guess properly the location of the desktop file out of the WM_CLASS property in the application window. Also, append a sha1 checksum to the filenames to avoid collisions.
I did a small change to use a utf-8 function for the strdown.
So after further discussion. * The current mapping is heuristic, I admit, but I really really want to try hard to avoid making it MORE heuristic. * Epiphany can change the logic for naming the .desktop files * Long term I'd actually like to remove the ' ' to '-' bit in the heuristic mapping. For fedora eclipse I bet the pid heuristic will work too. * We should probably write any heruistic state to a file so we're stateless across restarts (like the pid heuristic)
Review of attachment 196122 [details] [review]: OK.
Attachment 196122 [details] pushed as 66e093c - Normalize the web app profile directory and desktop file names
*** Bug 658012 has been marked as a duplicate of this bug. ***