Bug #16799
"amnesia" instead of "Home" launcher on the desktop
100%
Description
In bc022ef71e, the “Home” launcher on the desktop is now called “amnesia”.
I prefer “Home” because:
- It’s what we already had and it’s documented like this in many places (and screenshots).
- It’s the name of a place while “amnesia” is the name person, which is worse to label a folder.
- I’m trying to get rid of “amnesia” in Bug #15830.
Also the behavior and the layout of the launchers have change. Are there any technical reason behind that?
Subtasks
History
#1 Updated by intrigeri 2019-06-17 08:41:29
- Status changed from New to Confirmed
Background: IIRC the last decision wrt. desktop icons (when I proposed to remove them) was to keep them as long as it was not too costly. If that becomes too costly, we have other options (e.g. like Ubuntu, add a doc with Favorites, and move the current desktop icons to Favorites).
> I prefer “Home” because: […]
Agreed, let’s try to fix it, somehow (capped to 2h work time before we reconsider our options). Ideally this would be fixed (or at least) upstream if this is truly an upstream problem.
My next step would be to compare the version of the extension we’re shipping with current upstream Git and see if by chance, this might have been fixed already.
> Also the behavior and the layout of the launchers have change. Are there any technical reason behind that?
Support for managing desktop icons was finally removed from Nautilus, as announced since years. The GNOME folks were kind enough to write a GNOME Shell extension that re-implements this feature: https://tracker.debian.org/pkg/gnome-shell-extension-desktop-icons, https://gitlab.gnome.org/World/ShellExtensions/desktop-icons. I’m not surprised some appearance and behavior has changed.
#2 Updated by sajolida 2019-06-17 14:57:42
> Ideally this would be fixed (or at least) upstream if this is truly an upstream problem.
Right. I guess that upstream would also be interested in being
consistent with “Home” as it’s how the same folder is advertized in the
sidebar of the Files browser.
> The GNOME folks were kind enough to write a GNOME Shell extension that re-implements this feature: https://tracker.debian.org/pkg/gnome-shell-extension-desktop-icons, https://gitlab.gnome.org/World/ShellExtensions/desktop-icons. I’m not surprised some appearance and behavior has changed.
Thanks for the historical background. It makes sense and these other
changes not important :)
#3 Updated by hefee 2019-06-17 15:28:12
- Assignee set to hefee
#4 Updated by hefee 2019-06-17 16:47:41
- Assignee deleted (
hefee)
checked upstream - there is no change that fixes this. They just use the folder name to display. See desktopIconsUtil.js: getExtraFolders()
Other quick solutions:
- use a symbolic link to the home folder, that should fixes this. we don’t have translation for this.
- create a desktop file with
Type=Link, but we still need to update translations by ourselves.
#5 Updated by sajolida 2019-06-17 17:44:18
Thanks hefee for thinking about these workarounds. Unfortunately, if we can’t easily have translations it won’t solve the inconsistency issue and might be weird in some languages — eg. in Catalan “home” mean “man” :)
And to add another issue with keeping “amnesia”, the “Persistent” folder itself would be right inside the “amnesia” folder probably leading many users to scratch their heads….
Sooooo, maybe we should
- Drop this one launcher. We have the Places menu already.
- Or replace it with a launcher for the “Files” browser (hopefully translated).
We could also add “Files” to the favorites in the Applications menu.
Any of these options (as long as they are translated) would work for me.
Anybody has an opinion?
#6 Updated by intrigeri 2019-06-18 07:33:44
> Anybody has an opinion?
Unsurprisingly, I’m in favour the solution that likely has the cheapest implementation and maintenance cost, i.e. “Drop this one launcher. We have the Places menu already”. This seems to be feasible by setting one gsetting/dconf boolean to false: https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/blob/master/schemas/org.gnome.shell.extensions.desktop-icons.gschema.xml.
#7 Updated by intrigeri 2019-06-18 16:59:02
- Assignee set to intrigeri
#8 Updated by intrigeri 2019-06-18 17:05:53
- Status changed from Confirmed to In Progress
- Feature Branch set to bugfix/16799-hide-home-desktop-launcher
I’m doing both hiding this launcher and adding Files to the list of favorite apps.
#9 Updated by intrigeri 2019-06-18 18:26:46
- Status changed from In Progress to Needs Validation
- Assignee deleted (
intrigeri)
#10 Updated by intrigeri 2019-06-18 18:26:56
- Status changed from Needs Validation to In Progress
Applied in changeset commit:tails|c0d168afafd2d7d7024ad8496d89f46a209012ec.
#11 Updated by intrigeri 2019-06-18 18:30:31
- Status changed from In Progress to Needs Validation
#12 Updated by hefee 2019-06-19 08:13:31
- Assignee set to hefee
#13 Updated by hefee 2019-06-19 09:41:51
- Status changed from Needs Validation to In Progress
- Assignee changed from hefee to intrigeri
spin up a iso to look at and verified that the home launcher icon is not there anymore -> review passes can can be merged.
> I guess that upstream would also be interested in being consistent with “Home” as it’s how the same folder is advertized in the sidebar of the Files browser.
We found a workaround for Tails, it would still be nice to inform upstream about this issue.
#14 Updated by intrigeri 2019-06-19 09:46:42
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Applied in changeset commit:tails|f1f5c3b5c96994a042a1e0e5a0b80ada131da335.
#15 Updated by intrigeri 2019-06-19 09:57:28
> We found a workaround for Tails, it would still be nice to inform upstream about this issue.
https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/issues/140