The fact that this solution “overlaps” the icon below when selected adds some very nasty side-effects usability-wize.

Think about what happens when the top row files have very long filenames and the user selects them. Several rows below could “disappear” making them inaccessible, forcing the user to click an aditional time somewhere outside the selection in order to reveal the other files => more excise.

There are more problems.

How to distinguish between two files (when ellipsis is on) that are identical but just end differently ? When implementing an ellipsization feature, it should be “smart”. It has to be able to decide where its most suitable to shorten the filename (so users can find the files without having to click around everywhere). Its not enough to place ellipsis in the middle either, as the same problem might occur.

Always consider the side-effects that an implementation like this brings .

A better solution, would be to use some of the space taken by the icon, perhaps overlay the icon with the text.

However you look at it, arbitrary truncation is *not* the correct action. This an annoying usability issue with windows (and apparently other file managers), and until every file has metadata associated with it meaning we can store information in a sane manner, we are stuck with putting all our data into files, with names that describe them. The natural way to index a set of similar files is to SUFFIX an index onto a generic description, which when you’re dealing with piles of data may very well be several lines long.

Why do people in Gnome keep making really stupid usability regressions. Gnome 2.0 started so promisingly in a usability sense. Usability is not difficult, it just requires one to think carefully about the use cases and pay attention to the subtle details.

That all said, I do very much value the work you put in, so thanks for that.

Clearly, filenames can become too long (e. g., 10 lines seems too much) which somehow impedes usefulness of the icon view, so some amount of ellipsation seems neccesary. On the other hand, ellipsation of important information is clearly a loss of usefulness of the icon view, things that used to be visible at a glance are now hidden and require manual fiddling *every single time*. This will clearly punish users who made use of the old behvior to give their files descriptive names, and will in the worst case require them to manually rename several years’ worth of file names.

Increasing the number of lines might be a good idea, 4 lines is a size you can easily hit in normal usage, especially if one zooms out a bit. Using long words is also a big problem, as Nautilus will not split them unless neccessary, which will cause them to not fill up the lines completely and hit the information loss barrier earlier. Increasing the limit to 5 or 6 lines will cover more everyday uses while still stopping overly long file names, and might be a good idea.

Does it always show the extension? I can’t see it from your screenshot, if not it probably should. Whether it’s the png or xcf version of an image (or, say, a .c or .h file) can make a big difference, and this information will always be hidden first.

- the ellipsization should only take place on really long filenames (exact limit to be decided. compact layout may have a lower limit)

- ellipsis should be placed at the middle rather than end of the file name

may be this can spare us from another option in the preferences dialog.