Icon view sizes in Nautilus 43

I’m willing to volunteer my time to bring back the 64px icon size, previously named “standard”. Will you accept it?

1 Like

@ebassi please show me how I violated the COC and if I really did, then please ban me.

The issue is not adding a new size, or changing an existing size: that’s not even remotely what this is all about.

The issue is:

  • maintenance
  • design
  • future development

Please read the whole topic before leaving a reply.

I was eagerly considering asking for a feature change exception to allow back the 64px size for version 43.

But now I’m concerned that’s going to feed the toxic mindset that the best way to influence development is to bully the developers into submission.

1 Like

I apologize if any of my comments insulted you (now I noticed it was your commit), it was not my intention. No offense, but saying that you were considering to bring back the 64px icon size in 43 but now you won’t because of users comments is a little childish.

Anyway, have a good night.

“No offense, but” and misrepresenting what I said to call it childish doesn’t make your apology or your intentions seem honest.

1 Like

My apology was honest for my first comment. If you accept it or not is up to you. Also what you said about feeding the toxic mindset, looks childish to me.

As I said have a good night. I don’t want to get into an argument.

I just register for that.
Seriously, I don’t understand the election of sizes. For many users (1080p), 96, 168 and, obviously, 256 is large or super large. I suppose that some people use super screen with millions of trillions pixels and they need 256px icons. But many many users needs a couple of sizes for their setup. And now, it is not.
In fact, the main problem is using absolute values rather than relative values. Relative to the screen size, clearly. 256px in a 1080p screen is a quarter part size! Clearly no sense for the major of people. If you don’t have a problem in your eyes, you prefer to see at least more than 4 icons vertically…

So please, solve this issue.

1 Like

I understand that design decisions are often like looking into a crystal ball. But the removal of 64px icons is way too early in my opinion. I am acting as a sysop in an university and migrated hundreds of machines from KDE (or even worse Mac/Win) to (GNU/Linux) with Gnome while the last 3 years.
4k displays are definitely not the default size at the moment.

I bet this change will not go over well as soon as Gnome 43 has arrived in our GNU/Linux distribution. No offense but this would feel like a classical design decision made by MS.
Extended support for 64px icons for the next 5 years would be a smart and strategic decision in my opinion.

Don’t get me wrong, I thank all the developers for so many other very good things in Gnome! :slight_smile:

4 Likes

I would like to add my vote for a return of the 64px size. I just tried out the Fedora 37 Beta in VM on a 2K monitor (2560x1440) and was dismayed with the removal of the size. Instead of having Small, Medium, Large and Extra Large, what I have is Small, Large, Extra Large and Gargantuan. The problem is exacerbated when you have a Desktop Icons extension and it still has the Medium size icons. I use this size on all my monitors regardless of their resolution, be they 1080p, 2K or 4K. My current workaround is to switch Nautilus to List View, but I would much prefer the return of the Medium size.

Thank you for your time and for your efforts!

Disclaimer: As a new member of Gnome Discourse, I hope that my comments are indeed appropriate and respectful of others, in particular the developers whose passionate work we are truly grateful for.

In all honesty, I must admit that the change in thumbnail sizes (or “zoom levels”) is the first one that has ever bothered me since I switched to Linux a couple years ago, starting with Gnome 36 I believe.

António Fernandes has given us a comprehensive explanation for this change, starting with the introduction of 256px thumbnails five years ago which created the shift in sizes. Still, I have a hard time wrapping my head around two things.

First of all, how much “additional maintenance” would an additional thumbnail size constitute, as Emmanuele Bassi mentioned in his last comment? If I understood correctly, Gnome use to deal with five sizes for a number of years, so was it really an additional burden?

Secondly, can it really be assumed that those raising this issue do not represent a significant portion of users? While I agree that this conversation is skewed towards those who have been bothered by this change including myself (since we feel the need to express our disagreement, compared to the “silent approval” of other users), one must admit that getting rid of any default option (i.e., the 64px thumbnail size) is bound to affect a considerable number of users, especially those newer to gnome and Linux who presumably are less eager to tinker with the UX and more prone to adjust to its default layout. Moreover, I suspect most Linux users tend to value choice and options when it comes to essential things such as accessibility and usability. If this is the case, then knowing that a wide range of users on 1920x1080 resolutions might be affected by this change would preoccupy them regardless of whether they are personally affected by it.

On a final personal note, I would really appreciate it if it would be possible to file a feature change exception for the 64px size, but otherwise I hope our views will be considered for the next version of Gnome.

Once again, thank you for all of your incredible work with the Gnome desktop, and for any further clarifications on these points! :grinning:

1 Like

To let hear from the other camp: while I was on GNOME 42 and trying Files 43 from Nightly flatpak I thought the new thumbnail sizes would be bothering me. (I droned on to António a bit much about the differences in the issue. I apologize for that.) But after upgrading to GNOME 43, I haven’t noticed the difference in daily use and I do work with a lot of image files. I like the new design :slight_smile: I know a ton of work went into Files 43 and it shows!

Looking at Files 42 and 43 side by side, on the default icon sizes, the thumbnails for image files are a bit smaller in 43 but icons are actually the same size (look at a folder icon for example).

12 posts were split to a new topic: Grid view mockups and experiments

Setup: 4K monitor at 150% scaling.

I’m also looking at it from a folder icon and non-image document icon point of view, as this is the main context I’m working in.

The current smallest icon size results in:

  • text labels being wrapped to multiple lines more often, making them harder to read.
  • despite its direct margins being clickable as well, you try to hit the folder directly anyway. This gives you a much smaller surface to work with
  • it feels like the icons are smaller than what feels balanced with the rest of the Files interface. Especially because of the text labels size I suppose, since the sidebar icons are basically the same size. The label size can’t be made smaller either though

The icon size one step bigger results in:

  • less icons in view so needing to resize windows and scrolling more
  • clunky looking icons compared to the surrounding interface

I’m at one step bigger size icons for the time being for the lack of a better option. This option has the least disadvantages, but remains awkward.

My current monitor sizes, if it helps:

13" 4K (3840x2160) at 200%
15" 1920x1200 at 100%
24" 2K (2560x1440) at 100%
32" 2K (2560x1440) at 100%

(Different machines and/or setups, not all at the same time.)

On second thought, despite mentioning my screen size, it makes no difference. I use it with my 1080p laptop screen next to it with the exact same experience.

I can. Just make an AppImage after building nautilus. The following bash script works for me for Nautilus 43.1.

#!/usr/bin/bash -e
wget -c https://github.com/linuxdeploy/linuxdeploy/releases/download/continuous/linuxdeploy-x86_64.AppImage
chmod 755 ./linuxdeploy-x86_64.AppImage

meson setup build --prefix=/usr
meson install -C build --destdir=AppDir

glib-compile-schemas ./build/AppDir/usr/share/glib-2.0/schemas
gtk4-update-icon-cache -q -t -f ./build/AppDir/usr/share/icons/hicolor
update-desktop-database -q ./build/AppDir/usr/share/applications

mkdir -p ./build/AppDir
echo -n '#!/usr/bin/bash
export AppDir=$(dirname "$(realpath "$0")")
export PATH="${AppDir}/usr/bin:${PATH}"
export XDG_DATA_DIRS="${AppDir}/usr/share:${XDG_DATA_DIRS:-/usr/local/share:/usr/share}"
export TEXTDOMAINDIR="${AppDir}"/usr/share/locale:"${TEXTDOMAINDIR:-/usr/share/locale}"
export LD_LIBRARY_PATH="${AppDir}"/usr/lib:"${LD_LIBRARY_PATH:-/usr/lib}"
export GI_TYPELIB_PATH="${AppDir}"/usr/lib/girepository-1.0
nautilus "$@"
' > ./build/AppDir/AppRun
chmod 755 ./build/AppDir/AppRun

./linuxdeploy-x86_64.AppImage \
  --appdir=build/AppDir \
  -o appimage \
  --desktop-file=build/AppDir/usr/share/applications/org.gnome.Nautilus.desktop

Note: The AppImage built with this script will work only on the machine where it was built.

I just want to put this out here because I feel it’s important to be able to see what I’m seeing in terms of icon sizes and why we need the medium size returned. Following is a set of screenshots. The first two using OpenSUSE Tumbleweed and Gnome 43, the last using Red Hat Enterprise Linux and Gnome 40. All using the Papirus icon set and the last using adw-gtk3 theme in order to try and eliminate potential difference issues. The first screenshot is using the “small” icon ize, the second the “large” icon size, and the third using the “medium” icon size no longer available.

Okay, I think the discussion is constantly circling back to precisely the same arguments, and it’s just not useful any more, except for venting.

The issue is being worked on for GNOME 44 alongside more changes to the icon view:

And if the changes aren’t reading in time for GNOME 44, they’ll be delayed to GNOME 45, and so on, and so forth. Such is the cycle of every GNOME application.

Thanks everyone for your feedback: it’s been very helpful, and it has been taken into consideration for future changes.

1 Like