GNOME Bugzilla – Bug 729429
Update the favourite apps list for new nautilus and gnome-documents names
Last modified: 2014-07-22 12:21:28 UTC
Apps are slowly moving over to DBus activation and changing their desktop file names because of that. It's easy enough to update the defaults, but I think we should also do something with the list of favourites that are saved in users GSettings. Attaching a patch to that effect; it's not pretty but I guess it's better than having the file browser vanish on upgrades.
Created attachment 275702 [details] [review] Update the default favourite apps list for renamed desktop files Nautilus and gnome-documents have changed their desktop file names to support DBus activation.
Created attachment 275703 [details] [review] appFavorites: Automatically update desktop file names in user settings This adds a table with mappings for GNOME apps that have recently renamed their desktop files, and automatically switches over to their new names. Most importantly, it makes sure the file browser doesn't vanish on upgrades.
Review of attachment 275702 [details] [review]: Sure
Review of attachment 275703 [details] [review]: ::: js/ui/appFavorites.js @@ +27,3 @@ + if (appId == 'gnome-documents.desktop') + return 'org.gnome.Documents.desktop'; + else if (appId == 'nautilus.desktop') Considering that there'll be likely more entries in the future, I'd prefer a switch statement. (Also: if we are doing this, I don't see why we should restrict desktop id translation to ids in the default list - if a user had added gnome-clocks before the desktop file got renamed, it's as OK to have the icon disappear as the file manager ...) @@ +35,2 @@ reload: function() { + let ids = global.settings.get_strv(this.FAVORITE_APPS_KEY).map(this._updateAppId); This should be temporary, not something we'll have to maintain forever IMHO. So the problem here is that unless users make changes to their favorites, we keep storing the old id. Maybe we should instead check if there are ids that need translation and write out the translated list if that's the case?
Ryan wants to have a way of saying "Alias=" or something for legacy name compatibility.
That sounds much nicer, indeed.
Comment on attachment 275702 [details] [review] Update the default favourite apps list for renamed desktop files Attachment 275702 [details] pushed as 0832ca5 - Update the default favourite apps list for renamed desktop files
(In reply to comment #4) > This should be temporary, not something we'll have to maintain forever IMHO. So > the problem here is that unless users make changes to their favorites, we keep > storing the old id. Maybe we should instead check if there are ids that need > translation and write out the translated list if that's the case? Yes, saving it back makes sense to me. I can think of some edge cases where this could be unwanted, though: - developers with parallel jhbuild setup: if jhbuilt gnome-shell updates the favourites with the new desktop file names, it can cause stuff to disappear from the host system, because it's likely to have older apps. - corporations with e.g. RHEL 7 and Fedora 21 running from the same NFS home directory
Created attachment 275724 [details] [review] appFavorites: Automatically update desktop file names in user settings This adds a table with mappings for GNOME apps that have recently renamed their desktop files, and updates user settings with the new names.
I've updated the patch taking into account the review comments. It now saves back the updated favourite apps list and hopefully makes it easier to add more entries in the future. And I've added a few more desktop files to the list that I could find. Not sure it's actually worth committing this though if "Alias=" is coming soon.
another shell setting we need to update for these name changes is app folder configuration
To clarify: if we introduced this, it would have to be in the form of installing a desktop file with the _old_ name and having it look like: [Desktop Entry] AliasFor=org.gnome.NewName If we did it the other "obvious" way then the process of looking up a desktop file by its aliased name would be extremely slow (since you would need to search through all files looking for Alias= lines).
Yeah, that's what I meant. I think that's comfortable for most developers.
There are also a bunch of apps that have gone through, or are planning to go through several renames. e.g. gnomine.desktop -> gnome-mines.desktop in the 3.12 cycle, and likely going for org.gnome.Mines.desktop in the future.
Doesn't look like AliasFor has landed yet and 3.13.90 tarballs are due tomorrow. Can we go with the fix here and revert it when a better, alternative solution is ready?
Review of attachment 275724 [details] [review]: Sure.
Attachment 275724 [details] pushed as cceac0d - appFavorites: Automatically update desktop file names in user settings Thanks. I added a few more renamed desktop files I could find and pushed this.