Tails

#2 Updated by intrigeri 2019-11-22 11:27:41

sajolida, can you please triage this one?

I don’t think we can fix this without patching the corresponding GNOME Shell extension.

#4 Updated by sajolida 2019-11-29 11:19:46

> For some reason GNOME decided to break small aspects of what has been the standard behavior of desktops for decades.

My judgment was probably a bit harsh here as I don’t know if breaking
this was done on purpose.

I quickly looked for a GNOME ticket about breaking the drag-and-drop
from GNOME Files to the desktop and couldn’t find anything.

@intrigeri: If you already have more context information that me in your
head, do you think that it would be worth being reported upstream as
well? If so, to which GNOME component?

#5 Updated by intrigeri 2019-11-29 12:07:33

>> For some reason GNOME decided to break small aspects of what has been the standard behavior of desktops for decades.

> My judgment was probably a bit harsh here as I don’t know if breaking this was done on purpose.

I can hear that from a desktop icons user’s perspective it looks like careless breakage. I understand that one may disagree about GNOME’s design decision that desktop icons don’t make much sense in the context of a GNOME 3 desktop. Nevertheless, my impression is that on this topic, GNOME folks have been putting significant efforts into supporting something that they don’t believe in, and the way they communicated about these changes seems almost exemplary to me. IMO, right now we suffer from the consequences of not having paid much attention when they communicated about it 2 years ago: they started a conversation, asked for help, and we ignored all that, so well, it’s not a big surprise that our needs are not satisfied in the end. (Keeping in mind that we’re just discovering some of these needs now, as we had no idea what users were doing with desktop icons before!)

Here’s how the process looks like from my PoV:

1. GNOME 3, released in 2011, disabled desktop icons by default. Desktop icons management (via Nautilus) is opt-in. Desktop icons management with Nautilus has been buggy since about forever. It has caused us lots of trouble in Tails, upstream kinda gave up on it years ago, and it was bound to go away (as I wrote when I created Feature #11717).
2. Two years ago, the maintainers of Nautilus decided to drop the ball for real on this feature. They wrote a GNOME Shell extension to replace some of its basic features (frankly, I was surprised that they even bothered). They asked for help. I recommend reading the links I gave on Feature #11717#note-17, in particular https://csorianognome.wordpress.com/2017/12/21/nautilus-desktop-plans/, to better understand their reasons, how they managed this change, and what we can reasonably expect from them.
3. We ship the aforementioned GNOME Shell extension since Tails 4.0 and realize that it’s not doing everything that the previous, known broken, thing did.

> I quickly looked for a GNOME ticket about breaking the drag-and-drop from GNOME Files to the desktop and couldn’t find anything.

> intrigeri: If you already have more context information that me in your head, do you think that it would be worth being reported upstream as well? If so, to which GNOME component?

It would probably have had more chances to work if we had done this 2 years ago, but IMO the least we can do is to communicate our needs to the authors of this extension. I don’t know if it’s worth it in terms of short-term cost/benefits economics, but it’s very cheap, and to me it’s the bare minimum we can do to be decent participants in this relationship.

The software we currently use to manage desktop icons is https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/.

#8 Updated by sajolida 2019-11-30 16:06:41

Thanks for the additional info. I also got some useful pointer from GNOME. It gives me a better perspective and I can hopefully learn how to interact better with GNOME in the future.

It seems to me like GNOME made 2 very questionable decisions throughout this process and that they happened almost 10 years ago. First, they decided that they don’t believe in in the traditional desktop widget. Almost 10 years later Windows and macOS still use it pretty much unchanged and with them 97% of the global desktop users. Second, they decided to build technologies that made this decision irrevocable or very hard to revoke as per the history of the continuous degradation of the tools that tried to keep this desktop widget alive.

From what I can get of the design culture at GNOME from these posts, bug tracker comments, and GUADEC videos, indeed this was most likely based on believes (and a some choice-supportive bias) rather than on user research and a user-centered design process. One of the problems with this is culture, is that it seems very hard to influence such decisions unless you have a lot of power in the GNOME community or if you don’t do their user research homework for them. I don’t think that it would have made much a difference in the course of history even if a few more projects based on GNOME told them either 10 or 2 years ago that they might be going the wrong route or that they shouldn’t make an irrevocable decision. This culture is also not really motivating to get involved in design discussions with them as a small downstream project with super tiny resources.

Regarding what to do for the future:

In terms of software in Tails

We can either:

Continue swimming against the tide

We could continue reporting bugs against the desktop-icons extension about changes in behavior. We might also be able to switch to nemo-desktop. It works in Tails 4.0 (apt install nemo-desktop and Alt+F2 nemo-desktop) and suffers from less changes in behavior (file names are not truncated, drag-and-drop from the Files browser works, and free placing of items).

Stop swimming against the tide

And get rid of the desktop widget as you tried to suggest already in the past, cf. Feature #11717.

Assuming that it might be better to have no desktop widget than a broken one or one with an uncertain future.

For example, in the context of Tails, where anything put on the desktop will disappear when restarting, the whole thing makes less sense than on Windows and macOS.

We might move the “Tails documentation” and “Report an error” to the “Favorites” submenu as discussed in Feature #11717.

From Bug #17186, we learned that some people use .desktop file to launch custom applications. For example, when Electrum broke in Tails, tutorials online explained how to run Electrum 3.3.4 using a custom .desktop file: https://blog.thestever.net/2019/02/26/upgrading-electrum-on-tails-to-3-3-4/. Other people run other wallets from Tails using .desktop files as well: https://www.reddit.com/r/tails/comments/a7zgo4/help_to_create_a_desktop_icon_for_custom/.

In Tails 4.0 at least, putting a .desktop file on the desktop and choosing “Allow launching” is probably the only way of starting a custom program or script without ever opening the command line. I wouldn’t be surprised if other tutorials online documented this.

We could document https://www.reddit.com/r/tails/comments/a7zgo4/help_to_create_a_desktop_icon_for_custom/ in “Advanced topics” as it could also probably be done without ever opening the command line.

Understanding better the context, I don’t think that any of this is really urgent either and we can very well reject or postpone all these tickets about issues with the desktop.

In terms of GNOME ecosystem

I hope that I can learn from this whole story and learn better how to be more proactive regarding future changes in GNOME. I admit that I haven’t looked closely enough at this whole issue and it’s smaller UX implications until now. Partly because I don’t use the desktop myself neither to store files nor to start custom apps. My technical and organizational skills provide me better alternatives.

I have to acknowledge the problem that I have with what I see from the design culture at GNOME. Some of it might as well be unfounded, some of it might come from my interpretation of the GNOME 3 debacle, some of it might be pure laziness or lack of time. I’m happy to see from recent GUADEC videos that the design culture at GNOME might change a bit in the future but I don’t think that we have the resources to be a significant enough driving force there to make a significant difference.

I should start by following up more closely what’s going on at GNOME. I’m already subscribed to a bunch of mailing lists (desktop-devel-list@gnome.org, gnome-doc-list@gnome.org, devel-announce-list@gnome.org), but honestly, I’m not learning a lot from them.

I think that I was following Planet GNOME with a feed some years ago. I’m not sure why I’m not doing it anymore. Checking https://planet.gnome.org/, there doesn’t seem to have a general feed nor an easy of having an overview of many articles and pick the relevant ones.

Do you have any other tips on how to follow more closely what’s going on in GNOME?

#10 Updated by intrigeri 2020-04-16 10:10:51

Hi,

thanks for this very thoughtful post. I’ve meant to digest it and reply earlier, but I felt no urgency to it as it’s about long-term strategy.

I agree with the vast majority of what you wrote. I’m commenting on a few aspects below.

> h2. In terms of software in Tails
>
> We can either:
> Continue swimming against the tide
> […]
> Stop swimming against the tide

There’s a maybe a middle ground between continue/stop swimming against the tide: contribute code that makes the desktop-icons extension meet our needs.
It’s swimming against the tide of GNOME design decisions. But we would do it in a way that 1. integrates nicely with the GNOME ecosystem; 2. makes it clear that there is demand for desktop icons, and that some people care enough to invest into it, thus increasing the chances that other GNOME folks take this into account in the future.

> From Bug #17186, we learned that some people use .desktop file to launch custom applications […]
> We could document https://www.reddit.com/r/tails/comments/a7zgo4/help_to_create_a_desktop_icon_for_custom/ in “Advanced topics” as it could also probably be done without ever opening the command line.

I did not check technical feasibility, but I suspect we could equally make it possible and document how to add launchers to the Applications menu (or Overview) without using the command line, so that custom applications are reachable in the same way as applications installed by default, just like it’s already the case for Additional Software.

> Understanding better the context, I don’t think that any of this is really urgent either and we can very well reject or postpone all these tickets about issues with the desktop.

+1

> I’m already subscribed to a bunch of mailing lists (desktop-devel-list@gnome.org, gnome-doc-list@gnome.org, devel-announce-list@gnome.org), but honestly, I’m not learning a lot from them.

I understand GNOME moved most discussions to Discourse and traffic on mailing lists has dropped significantly.

But even before that switch, there’s lots of stuff I never saw discussed on mailing lists. I suspect that similarly to Tails, many discussions happen either on IRC or on the issue tracker — sometimes appropriately, sometimes failing to include stakeholders that don’t follow All The Things.

> I think that I was following Planet GNOME with a feed some years ago. I’m not sure why I’m not doing it anymore. Checking https://planet.gnome.org/, there doesn’t seem to have a general feed nor an easy of having an overview of many articles and pick the relevant ones.

I don’t understand. Would https://planet.gnome.org/atom.xml help?

> Do you have any other tips on how to follow more closely what’s going on in GNOME?

I would recommend reading the GNOME release notes, if you don’t do that already.

And perhaps there are areas/tags of https://discourse.gnome.org/ that could be interesting to you.
I appreciate it’s a new tool to learn, which has a bootstrapping cost.