Bug #16283
No more icons on desktop in buster
100%
Description
GNOME upstream removed support for icons on the desktop, which means our documentation link disappears in buster.
Unfortunately, that’s also what we’re using to make sure the desktop is ready.
Plan so far: check whether including the gnome-shell-extension-desktop-icons package (currently only in experimental) can bring back the old behaviour; installing that package isn’t sufficient as links aren’t clickable by default, and their icons aren’t displayed either; right-clicking on them and allowing execution does the trick though (with an extra curvy arrow that needs to be taken into account); hopefully only a matter of settings.
If that takes too much time, removing icons entirely is an option.
In the meanwhile, the relevant image check will be disabled.
Files
Subtasks
Related issues
|
Related to Tails - |
Resolved | 2018-02-17 | |
|
Related to Tails - |
Resolved | 2018-04-09 | |
|
Related to Tails - |
Resolved | 2017-07-12 | |
|
Related to Tails - |
Rejected | 2016-08-25 | |
|
Related to Tails - |
Resolved | 2017-10-06 | |
|
Related to Tails - |
Resolved |
History
#1 Updated by intrigeri 2019-01-05 10:28:40
- Status changed from New to Confirmed
#2 Updated by intrigeri 2019-01-05 10:31:51
- related to
Bug #15321: "The Report an Error launcher will…" test suite step is fragile added
#3 Updated by intrigeri 2019-01-05 10:32:08
- related to
Bug #15514: The "The Tails documentation launcher on the desktop works…" scenarios are fragile added
#4 Updated by intrigeri 2019-01-05 10:32:28
- related to
Bug #13461: The Desktop icons are sometimes not displayed since the upgrade to Stretch added
#5 Updated by intrigeri 2019-01-05 10:32:39
- related to
Feature #11717: Drop launchers from the Desktop added
#6 Updated by CyrilBrulebois 2019-01-05 10:37:11
- Status changed from Confirmed to In Progress
Applied in changeset commit:tails|f211f51b58c0b88c74b8a4b3e27fa62a51aac2a6.
#7 Updated by CyrilBrulebois 2019-01-05 12:07:50
This seems to work:
- Install
gnome-shell-extension-desktop-iconsfromexperimental
→ That one could probably be imported todeb.tails.boum.org - Enable the extension in
gnome-shell-extension-prefs
→ That could probably be done by tweakingconfig/chroot_local-includes/etc/dconf/db/local.d/00_Tails_defaults - Mark the
*.desktopfiles as trusted:gio set foo.desktop metadata::trusted true && touch foo.desktopfrom an opened session (the gio call alone doesn’t seem sufficient forgnome-shellto notice the change, thetouchcall triggers a desktop refresh).
→ That part is likely a little harder as it seemsgioshould be called from an opened session; I’ve seen many people recommend an autostart script, so that it happens when the session is started.
Next step would be making sure the autostart stuff works, unless the whole thing looks crazy?
(Time spent so far: 1h; expected remaining time if we go for this solution should be no more than 1h.)
#8 Updated by intrigeri 2019-01-05 12:23:21
> This seems to work:
> * Install gnome-shell-extension-desktop-icons from experimental
> → That one could probably be imported to deb.tails.boum.org
I’d rather pull it from Debian until we can’t do it anymore:
- This extensions is very recent and still under fast development so I suspect we’ll want to track the latest available version at least for the next few months.
- It’s arch:all.
- There’s still some hope that the package makes it into Buster, in which case I hope we can just take that version and avoid dealing with a special case here.
And whenever we can’t do this anymore, sure, we’ll have to upload to our custom APT repo.
> Next step would be making sure the autostart stuff works, unless the whole thing looks crazy?
Go, go, go!
I’m quite hopeful that this new setup will fix some of the long-lasting issues caused by Nautilus handling of desktop icons (see the related tickets).
#9 Updated by CyrilBrulebois 2019-01-05 13:17:34
ACK regarding the fetching from Debian bit, almost mentioned it but then got side-tracked.
And OK for keeping on with the investigation. I haven’t checked the tickets but I’ve seen some workarounds in the test suite regarding cases where nautilus needed to get poked…
#10 Updated by intrigeri 2019-01-05 15:19:10
Also, regarding the autostart thing: it’s caused too much trouble to us in the past and is painful to debug, so everything got converted to systemd --user units a while ago, see config/chroot_local-includes/usr/lib/systemd/user/. I don’t know which target it should be part of though.
#11 Updated by CyrilBrulebois 2019-01-05 15:52:21
- File tails-desktop-icons.png added
- Assignee deleted (
CyrilBrulebois) - QA Check set to Ready for QA
It seems my first shot at writing an autostart script does the job (icons are back!). Please check:
b8a9438cbb..49b9376baf HEAD -> feature/busterIt might be possible to simplify the /bin/sh, for loop, quoting, etc. things but I wanted to play safe for this first test.
I’m attaching a screenshot, we’ll need to adjust test suite images anyway, due to the (different in size) shortcut arrows on top of the desktop icons.
#12 Updated by intrigeri 2019-01-05 16:44:55
- Assignee set to CyrilBrulebois
- QA Check changed from Ready for QA to Info Needed
> It seems my first shot at writing an autostart script does the job (icons are back!).
\o/
> I’m attaching a screenshot, we’ll need to adjust test suite images anyway, due to the (different in size) shortcut arrows on top of the desktop icons.
Before you update these images (to avoid having to do it again later): can we have the icon size closer to what we have on Stretch?
#13 Updated by hefee 2019-01-06 11:11:09
- Assignee changed from CyrilBrulebois to hefee
#14 Updated by hefee 2019-01-07 12:14:11
- File Screenshot_20190107_131348.png added
> Before you update these images (to avoid having to do it again later): can we have the icon size closer to what we have on Stretch?
- Unfortunately gnome-icon-theme ships system-help only in 48x48 resolution, that is the best we can get at the moment. The actual system-help.svg is not shipped within the binary package :( The bug is open since 2010: https://bugs.debian.org/580256.
- copy this svg into config/chroot_local-includes/usr/share/icons/gnome/scalable/categories/system-help.svg and fix this upstream.
- switch to tails-help logo
- Whisperback uses a svg so GNOME scales everything on its own.
- the extra desktop is not necessary, systemd user units take care of it namely:
config/chroot_local-includes/usr/lib/systemd/user/tails-add-GNOME-bookmarks.service
with:
After=gvfs-metadata.service
Requires=gvfs-metadata.service
WantedBy=desktop.target
#15 Updated by hefee 2019-01-07 12:27:11
- File Screenshot_20190107_132617.png added
#16 Updated by hefee 2019-01-07 16:47:05
- File Screenshot_20190107_165104.png added
- File Screenshot_20190107_173606.png added
The patch works for me. But in terms of clearness, I’m not 100% satisfied, that setting the metadata for Desktop icons is done in a script called add-GNOME-bookmarks as the task has nothing to do with bookmarks.
#17 Updated by hefee 2019-01-07 16:47:39
- related to
Bug #14793: Custom Desktop launchers are totally buggy added
#18 Updated by hefee 2019-01-07 16:50:35
- Assignee deleted (
hefee) - QA Check changed from Info Needed to Ready for QA
The initial implementation of metadata::trusted yes was done in Bug #14793 by @intrigeri.
A small side fix is to bring back KeePassXC to favorites list, as KeePassX was there before. (Feature #15297)
#19 Updated by intrigeri 2019-01-07 18:55:21
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
- QA Check changed from Ready for QA to Pass
LGTM, merged with one commit on top.
#20 Updated by CyrilBrulebois 2019-01-09 22:35:31
Do we consider “blue icon on blue background” to be an (arguably) accessibility issue?
Just mentioning in passing since I was wondering where the green icon went with a recent build. :)
#21 Updated by intrigeri 2019-09-07 09:33:15
- related to
Bug #17030: Missing "Tor Browser" shortcut in the Places menu added