Project

General

Profile

Bug #17243

Desktop icon's lable fail to resize for long names

Added by bolenh 23 days ago. Updated 11 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Wait
Blueprint:
Starter:
Affected tool:

Description

To repro:

1- Place a file with a long name on the desktop, a name that exceeds the size set to display it under the file's icon.

2- Single click on the file to highlight it.

Expected behavior:

File highlighting / selecting should trigger auto-resize so that the whole file's name is displayed and not trimmed to default file icon's label size.

Actual behavior:

The above doesn't happen, instead the file name is still trimmed to default size which has no space to show the rest of the file name.


Related issues

Related to Tails - Feature #11717: Drop launchers from the Desktop Rejected 08/25/2016
Related to Tails - Bug #17180: cant wipe files on desktop New
Related to Tails - Bug #17193: Can't run .desktop files from the desktop anymore Resolved

History

#1 Updated by intrigeri 19 days ago

#2 Updated by intrigeri 19 days ago

sajolida, can you please triage this one?

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

#3 Updated by sajolida 13 days ago

  • Status changed from New to Confirmed
  • Type of work changed from Code to Wait

The desktop in general has generated a lot of complains from users in general so I had a closer look at what happened since 3.16 and how Ubuntu 19.10 is doing.

From some reason that I didn't investigate further, GNOME 3.30 introduces a bunch of significant changes in the way the desktop behaves, both in Tails 4.0 and Ubuntu 19.10:

  • You can't drag and drop files (or launchers) from GNOME Files to the desktop itself anymore. You can still move them to the Desktop folder and then they appear on the desktop.
  • You can't move freely file on the desktop. They are automatically aligned to a grid.
  • As described by bolenh, when selecting a file with a long name on the desktop and selecting it, it doesn't appear fully. See screenshot in attachment.

The way that the desktop behaved in Tails 3.16 (free drag & drop) is the way that the desktop behaves on Windows and Mac. For some reason GNOME decided to break small aspects of what has been the standard behavior of desktops for decades. Meh...

Still, the behavior reported by bolenh looks more like a bug to me.

Actually, it has already been reported to GNOME but received little interest so I commented on it with screenshots and all:

https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/issues/122

#4 Updated by sajolida 12 days ago

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 12 days ago

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 #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 #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/.

#6 Updated by sajolida 11 days ago

  • Related to Bug #17180: cant wipe files on desktop added

#7 Updated by sajolida 11 days ago

  • Related to Bug #17193: Can't run .desktop files from the desktop anymore added

#8 Updated by sajolida 11 days ago

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. #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 #11717.

From #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 (, , ), 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?

Also available in: Atom PDF