GNOME Bugzilla – Bug 84390
We should truncate long icon label text with an ellipses and then show the full name on mouseover, as Windows does.
Last modified: 2008-08-18 15:15:35 UTC
Problem: Currently, our icon view layout is very messy looking, due to bad wrapping of long icon labels which results in labels being rendered like this: Bullets- dont-line-
Oh drat. That accidently got submitted with a "spacebar" press. Sorry. I will finish the bug report now. Problem: Currently, our icon view layout is very messy looking, due to bad wrapping of long icon labels which results in labels being rendered like this: Bullets- dont-line- up-to- add-a- menu-to- a-panel. png This causes a ton of whitespace to be left around all the other icons on the row that don't have long file names. Not truncating at a fixed width also causes use to be unable to evenly space icons on a single row. Lastly, not truncating makes it difficult for us to avoid having desktop icon labels running off the side of the display. I think there are other benefits I haven't thought of yet.
anders said this problem would need to be fixed in Pango.
This would rock, and would probably fix most of the icon view layout problems.
Comments from the usability crowd? It sounds like something we want to me.
If i remember correctly i think this is what windows and mac do too....
It's definitely what Windows does. Not sure about MacOS or OS/X. I think this approach would simplify the layout code tremendously, which would make it more robust and easier to maintain.
Now if we could only add windows style automatic layout, than i'd be inheaven....
No idea why this belongs in pango but it would be very nice to get in. Doing the right thing and marking as enhancement and reassigning.
This needs to be left on nautilus (not pango/docs) and just depend on bug 50971, if you want to indicate depenency on ellipsization support in Pango.
You mean bug 59071
moving back to nautilus, per owen.
*** Bug 75209 has been marked as a duplicate of this bug. ***
So what exactly needs to change to implement this feature? After having Jacob show me how OS/X does this, I've decided I like the OS/X implementation event better than Windows' approach. Is getting this in for Gnome 2.2 doable?
Updating CC list.
Just another "me too" on this bug. Might I suggest that the text not be truncated when the mouse cursor hovers over the icon, or when the icon is the current selection. And by "current selection", I mean "the icon that was most recently clicked on", not "all of the icons that are selected". Windows distinguishes between these by highlighting all that are selected, and drawing a dashed outline around the currently selected icon. I don't know if Nautilus makes this distiction.
*** Bug 127713 has been marked as a duplicate of this bug. ***
*** Bug 99323 has been marked as a duplicate of this bug. ***
Now that pango can elipsise things properly is this something that can be implemented now? Is it on the radar for gnome 2.9 development cycle?
Yes, pango can ellipsize since version 1.6 (i.e. GTK+ 2.4) [1]. [1] http://developer.gnome.org/doc/API/2.0/pango/pango-Layout-Objects.html
I completely agree with this. With many applications using long file names these days (i.e. mp3s, video files, etc.), this feature would greatly improve the look of the desktop.
Perhaps I'm in the minority here, but I greatly prefer the current behavior, and actually miss this functionality when I'm using Windows. With Windows, I find the icon view useless, as it truncates file names to the point where I can't distinguish one from another, forcing me to use the less attractive "Details" view - similar to "List" view in Nautilus. While the layout in Nautilus is sometimes disturbed, I'd take that over the loss in information. If this feature is desired, could there be an option to enable/disable it somehow? (I wouldn't mind having to go through gconf to do it.)
Perhaps we could apply ellipsization only to files with names significantly longer than the average of the rest of the files in the given row, like so: [ ] [ ] [ ] [ ] File 1 File 2 Long..name3 File 4 But not to truncate in a case like this: [ ] [ ] [ ] [ ] Long Long Long Long File File File File Name 1 Name 2 Name 3 Name 4 Names that have a lot of newlines will still be ugly, but maybe with a little more magic (i.e. detect when there's a lot of files with long names in one folder, to increase the label width.
damn... i thought this was fixed in gnome 2.10 :( CC'ing...
*** Bug 321836 has been marked as a duplicate of this bug. ***
Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/nautilus/+bug/30875
*** Bug 326967 has been marked as a duplicate of this bug. ***
Here we are, nearly four years down the road from when I submitted this request. Can we _please_ get this dealt with? I have been testing Ubuntu Dapper and Fedora Core 5. Both of these desktops currently display horribly laid out icons (text hidden behind icons, big gaps between some icons and not enough space between others). Typically, problems are arising when file icons are rendered on top of drive partition icons. Also, I am seeing problems arise when content previews are mixed with file and partition icons. I am seeing horizontally staggered icons in a column, etc. Anyhow, I recongnize I need to check whether these layout problems have open bug reports and, if none exist, open new ones. Still, this feature request, as I have said before, would likely simplify a lot of the code pertaining to icon positioning.
Hello, is anyone paying attention to this bug report? Is there any point in filing bug reports? I thought this was supposed to be a community effort.
People pay attention to bugs, but there is almost one thousand bugs open on nautilus and only few people contributing to it. Usually the priority is rather to fix crashers, potential data loosing, and other annoying issue because cosmetic changes like that one. It doesn't mean that nobody is interested to work on that but people work on their free time on that or are really busy with other projects too so it takes some time. As you say that's a "community effort", which means that you are welcome to contribute by sending a patch too if you want. Other way it'll probably be fixed at some point when somebody gets enough interest to it
Can you point me to the Nautilus files that handle icon layout on the desktop? I will take a look at the code and take a stab at creating a patch. Thanks.
I'll take a peak in the code of nautilus to see if i can help. For the file i'll guess it would be in libnautilus-private as nautilus-icon-* OR my other guess would be in libnautilus-file-manager as fm-icon-* Correct me if i'm wrong.
*** Bug 322564 has been marked as a duplicate of this bug. ***
omg!! still not resolved.. :( i did some searching through the gnome nautilus coding and i think the place to edit the file is where ever this function is created: nautilus_file_get_display_name() than edit it with a truncate function or a substr (got that name from php) function. substring examples: c++ example: ---------------------------- string my_string = "abcdefghijklmnop"; string first_ten_of_alphabet = my_string.substr(0, 10); cout<<The first ten letters of the alphabet are " <<first_ten_of_alphabet; ---------------------------- i don`t exactly know if it`s really a c++ example but it was listed onder a c++ chapter.. i would have tried to do this stuff myself IF i know where i need to be and how to do that c(++) stuff :) i`m gonna learn it though. the file you probably need to have is: ./nautilus/src/file-manager/fm-icon-view.c arround line 1900 this is NOT the file where that function is being created.
oke... i know php is written in c and c is what gnome needs... my previous example was c++ but now i just searched through the php coding in a hunt for the "substr" function and i found it. this is the code: ----------------------------------------------------- /* {{{ proto string substr(string str, int start [, int length]) Returns part of a string */ PHP_FUNCTION(substr) { zval **str, **from, **len; int l; int f; int argc = ZEND_NUM_ARGS(); if (argc < 2 || argc > 3 || zend_get_parameters_ex(argc, &str, &from, &len) == FAILURE) { WRONG_PARAM_COUNT; } convert_to_string_ex(str); convert_to_long_ex(from); if (argc > 2) { convert_to_long_ex(len); l = Z_LVAL_PP(len); } else { l = Z_STRLEN_PP(str); } f = Z_LVAL_PP(from); /* if "from" position is negative, count start position from the end * of the string */ if (f < 0) { f = Z_STRLEN_PP(str) + f; if (f < 0) { f = 0; } } /* if "length" position is negative, set it to the length * needed to stop that many chars from the end of the string */ if (l < 0) { l = (Z_STRLEN_PP(str) - f) + l; if (l < 0) { l = 0; } } if (f >= Z_STRLEN_PP(str)) { RETURN_FALSE; } if ((f + l) > Z_STRLEN_PP(str)) { l = Z_STRLEN_PP(str) - f; } RETURN_STRINGL(Z_STRVAL_PP(str) + f, l, 1); } /* }}} */ ----------------------------------------------------- if you want to know what you can do with substring look here: http://nl2.php.net/substr i hope this helps to write a little hack for gnome to have that truncated stuff for once and for all. and here is the idea how i think this stuff should look in gnome. normal state (so just an icon with text and not clicked on) limit it to display the first 50 characters with 3 dots at the end. total chars is 50 including the dots. example: normal = 01234567890123456789... hover = 01234567890123456789.txt hover (or mouseover whatever you want) state: show all text. mouseout: again the 50 characters and not just this.. in the gnome config panel (edit -> settings (correct me if i`m wrong about that)) there shoutld be a switch to use truncated names or full names the truncated stuff should be on though. o and this stuff really must be in by the time gnome 2.18 gets released!! even xfce has this!!
i just found out something interesting about this... this is what i just did: i was sick of the of the gnome behaviour that every window click on a folder opened up in a new window so i started searching how to get the old style back.. which is the browser view style.. so i enabled that and to my surprise there also was a side pane!! (never saw it before in gnome.. i saw the name a few thimes in gconf-editor so i knew it must be somewhere in gnome.. i just didn`t found it in action yet.. till now. now when you put the side pane on: "Information" now the interesting part comes.. start playing a bit with the width of the side pane and you will notice that the icon and text are adjusting sizes.. THAT is also what is needed on the desktop in a slightly modified way :) so no need to make this stuff all over again to use it on the desktop :) just use this instead :) i sure hope this information is usefull for someone :) and just incase you don`t know how to turn on the browser and side pane.. open up gconf-editor and go to: apps -> nautilus -> preferences and enable: "always_use_browser" that should be it.. the side pane is on by default when the browser mode is enabled.
Created attachment 76024 [details] [review] Provides the feature of shortened filenames in nautilus According to Bug #84390 there is a feature request for reducing the filenames displayed in nautilus to a maximum length. So I wrote a patch which should provide this. Apply it in nautilus root folder with strip count 0. The gconf value /apps/nautilus/icon_view/truncate_displaynames determines whether truncation is made or not. The value /apps/nautilus/icon_view/truncation_length stores the maximum count of characters displayed per file. The truncation takes place in the function fm_icon_container_get_icon_text of fm-icon-container.c. Following the behavior of e.g. windows, the file which was selected at last by a mouse click, through arrow keys or through letter keys, should have a fully-written filename, so I added the member last_clicked_icon to the IconContainerDetails struct. I also had to change the scoping range for fm_icon_container_get_icon_text. Originally, fm_icon_container_get_icon_text had a reference to the applying NautilusIconContainer and the NautilusFile through NautilusIconData. Anyway, the function now needs a reference to the applying Icon, so I passed the applying NautilusIcon to fm_icon_container_get_icon_text through NautilusIconData *data. This is not done in a type-safe way but simply by casting the NautilusFile* to NautilusIconData* and backwards, because I didn't want to change too much in the function prototypes, so this urgently needs to be made type-safe. I also added the members truncate_displaynames and truncation_length to the IconContainerDetails struct, which shall simply contain a copy of the gconf values. The last_clicked_icon is updated when a mouseclick occurs (handle_icon_button_press), when an arrow button is pressed (keyboard_move_to) and when a letter button is pressed (button_press_event), so there might be some cases when the filename is truncated when it shouldn't which I haven't found so far. A change of the last_clicked_icon causes the IconContainer to repaint completely.
First off, let me say thanks for working on this! I ran into a glitch testing your patch. I built from Ubuntu sources: apt-get source nautilus cd nautilus-2.16.1 patch -p1 < /home/miles/truncate_displaynames.patch After building and rebooting, I get the following crash: Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.1 2006-10-02 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 115986432 vsize: 0 resident: 115986432 share: 0 rss: 21995520 rss_rlim: 0 CPU usage: start_time: 1162746757 rtime: 0 utime: 100 stime: 0 cutime:92 cstime: 0 timeout: 8 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/nautilus' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1227028816 (LWP 16556)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 83274
Thread 1 (Thread -1227028816 (LWP 16556))
Did you create a debian package using dpkg-buildpackage -rfakeroot -uc -b ?
I just tried that method but I can't build the packages (busted toolchain?): dh_gencontrol -pnautilus dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends} dh_md5sums -pnautilus dh_builddeb -pnautilus dpkg-deb: building package `nautilus' in `../nautilus_2.16.1-0ubuntu3_i386.deb'. tar: -: file name read contains nul character dh_gencontrol -pnautilus-dbg dh_md5sums -pnautilus-dbg dh_builddeb -pnautilus-dbg dpkg-deb: building package `nautilus-dbg' in `../nautilus-dbg_2.16.1-0ubuntu3_i386.deb'. tar: -: file name read contains nul character dh_gencontrol -plibnautilus-extension1 dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends} dh_md5sums -plibnautilus-extension1 dh_builddeb -plibnautilus-extension1 dpkg-deb: building package `libnautilus-extension1' in `../libnautilus-extension1_2.16.1-0ubuntu3_i386.deb'. tar: -: file name read contains nul character dh_gencontrol -plibnautilus-extension-dev dh_md5sums -plibnautilus-extension-dev dh_builddeb -plibnautilus-extension-dev dpkg-deb: building package `libnautilus-extension-dev' in `../libnautilus-extension-dev_2.16.1-0ubuntu3_i386.deb'. tar: -: file name read contains nul character dpkg-genchanges -b
Wonderfull :D i will try to put this patch in the fedora nautilus file :) (nope i`m not a fedora packager.. just a user) it would be gread if you vould add those settings in the nautilus Preferences window aswell.. anyway thanx alot so far
oke.. just tested some more.. desperate to get it working on fedora core 6.. and it just doesn`t want to work.. :( perhaps i will just need till: - someone makes a fedora package - it gets build in nautilus in the next version - or till the next fedora version where this couldbe in if it gets build in nautilus ofcause..
Mark, would you please be specific about what you tried and what went wrong? In my case, the Ubuntu .deb files didn't build and when I "make all install" nautilus crashed when I logged in. Hopefully, we'll get these wrinkles ironed out soon.
Since the original bugzilla report was about Nautilus icon view being very messy looking, I think the problem is still not completely solved: image and video previews make Nautilus suffer from the same messy looking, when having Image/Videos stored in the same directory with other files. I think we should give a fixed space icons and previews, not making icons having a smaller grid than previews have. Hope I expressed myself correctly.
I agree, fixed space icons really would improve the look of nautilus. If anyone of you uses ubuntu or debian, type apt-get source nautilus sudo apt-get build-dep nautilus apply the patch via patch -p0 < [patch] build a debian package via dpkg-buildpackage -rfakeroot -uc -b shut down you X server via sudo /etc/init.d/gdm stop deinstall you nautilus via sudo apt-get remove nautilus install the debian package via sudo dpkg -i [package.deb] start your X server via sudo /etc/init.d/gdm start at least, that's how I did it. It works fine on my machine and some others, didn't have any problems installing so far.
Just randomly breaking the filename at N bytes is totally wrong. It will cause invalid utf8 (and thus crashes), it will break on different length depending on what unicode chars are in the string, and it will do things totally wrong on things like bi-directional text. As the bug says, you should use the pango ellipzation feature for this: http://developer.gnome.org/doc/API/2.0/pango/pango-Layout-Objects.html#pango-layout-set-ellipsize
alexl, is it possible you could implement this quickly, since you seem to understand the issues very well?
I GOT IT WORKING :D i probly made a mistake while compiling it and making the rpm files.. o well.. it`s working now i`m gonna try and expand it a bit.. and i have no c++ knowledge so that can be funny
Mark, are you following Alex's guidance?
Miles, alex guidance? like in that link he posted here.. nope :) i`m just gonna try and add a number of dots key for in gconf-editor.. so i`m just gonna play a bit with it.. it`s likely that nothing will work because i don`t have any c++ knowledge and this isn`t exacrtly EASY to start with ;)
that seem pretty simple since it's ellipsize from the pango layout, I'm experimenting some stuff right now and the text is ellipsizing itself but the layout is pretty hazardous for now. The biggest lack i see for now is that the pango way give us a limitation for a 1 line, but what is interesting us is a 2 or 3 line wrap before. I can come up with a fast implementation for the list view but for the icon view it may be longer since the patch may affect pango directly... I'll post a patch in the later days for the list view minimally.
Steve, that`s wonderfull :) but why is pango needed to do this truncating in nautilus?can`t it just simply be done in c coding? probly alot faster also
Created attachment 76403 [details] here what it does with 1st version patch Here is what it does with the 1st version patch. See the mise alignement
Not really faster in my sense, but my goal is to have a clear code so that the nautilus dev don't blame me for inserting a crappy hack. Cause that what it would be and as a dev myself, I hate stumbling in this kind of code. It's much better to work out a pango patch and a nautilus patch so other software that use pango, could use this feature. This way it will be a much nicers structure and it would be as fast if not faster because the work will be done in graphics and since it's C all the ways, it's does not change much thing. I'll attach the patch and it's simplicity and show you what it does. You'll see why some work need to be done in pango to have a wrap et ellipsize combination.
Created attachment 76404 [details] [review] And the patch This is what I've done so far, it's not much but it's much simpler.
that looks ugly.. perhaps it would be best if the nautilus devs made a solig snap grid in nautilus.. and a max icon size cause now a screenshot is way to big if you compare it with the icons...
As one of the authors of the original nautilus icon view, the Finder icon view and the labeled icon item that Finder uses to display text and perform truncation, I have a few observations based on my experience. Miles' original bug pointed out what some may perceive as a major flaw in the design of the Nautilus icon view. The icon layout allows icon sizes and test lengths of an arbitrary size. The idea was that people would create icons of various sizes. You could drag an icon to an arbitrary size. This leads to non-uniform grid spacing. If you add a very long label line, you get an icon item that affects the entire layout. Andy thought this was a neat feature. You could then zoom the entire icon view in and out. At one time, you could do the same thing in Finder. The feature was rejected for aesthetic and usability reasons. The giant icons would cause unbalanced column/row layouts and some people really disliked it. A design based on fixed grid dimensions was implemented and a maximum label height of two lines was established. The maximum width of icons and labels were also set on what people thought looked the best. If you have seen the Leopard Finder, you will notice that there is a slider in the view options panel that allows the user to make grid spacing tighter. This essentially reduces the max allowable width of the label, pinning the minimum at the width of the icon. We did this as a response to people who didn't like our default choices. Finder still does not allow you to set the default number of label line or icon sizes. Here are some possible options the improve the look of the layout: Set a user-configurable limit on the number of label lines allowed before truncation. For most users, who do not resize their icons, this will create a nice layout. The layout grid will default to using general text metrics for the height of two line, plus the default icon sizing info, to create the layout grid. I would also suggest middle truncation, with a mouse hover revealing the entire label text. I don't know if you need to expose the max lines in the nautilus UI, perhaps just in gconf. Create a view style that disables variable icon sizes. The resizing controls are disables and icons dragged into the view are forced to have the same dimensions as all other items. I never really missed icon stretching in Finder, and now that I am back using Nautilus full-time, I don't have occasion to use it. I view it as a UI idea that Andy had and he wanted to explore. I would love to hear from Nautilus users who really use it a lot. I find that having the ability to scale all icons to be more powerful. I also find a clean, easy to scan grid layout to be important. It would be easy enough to tweak a few things and keep the icon stretching as well as adding max line counts and truncation. A solution could be found that would appeal to all user of the various icon view features.
Well, i was a full time nautilus user but i quit gnome because of the bugs i needed to fix manually!! i was using 2.16.1 on Fedora Core 6 the bugs i needed to fix: - This truncating - the "Nautilus ignores umask" bug i was using the default nautilus settings and was having oversized screenshot images.. and on top of that the text was all displates so basicly those 3 points caused me to get back to using KDE.. another thing is the nautilus mode.. the browser mode is good to use.. the other mode gives way to much windows on the screen. Gnome is a good project but i feel more at home in KDE till atleast the bugs i described here are fixed.. (if KDE had the GCONF it would rock :D)
(In reply to comment #56) > As one of the authors of the original nautilus icon view, the Finder icon view > and the labeled icon item that Finder uses to display text and perform > truncation, I have a few observations based on my experience. [...] Thanks for the background info. > Here are some possible options the improve the look of the layout: > > Set a user-configurable limit on the number of label lines allowed before > truncation. For most users, who do not resize their icons, this will create a > nice layout. The layout grid will default to using general text metrics for > the height of two line, plus the default icon sizing info, to create the layout > grid. I would also suggest middle truncation, with a mouse hover revealing the > entire label text. > > Create a view style that disables variable icon sizes. The resizing controls > are disables and icons dragged into the view are forced to have the same > dimensions as all other items. This sounds fantastic! The challenge seems to be getting the right people (Nautilus coders, and related Gnome corporate management) to agree to make it a priority and get it implemented. > I never really missed icon stretching in Finder, and now that I am back using > Nautilus full-time, I don't have occasion to use it. I view it as a UI idea > that Andy had and he wanted to explore. I would love to hear from Nautilus > users who really use it a lot. I find that having the ability to scale all > icons to be more powerful. I also find a clean, easy to scan grid layout to be > important. I have heard from a few committed users of stretched icons. I've tried to understand why they love the feature, but I just can't wrap my mind around it. > It would be easy enough to tweak a few things and keep the icon stretching as > well as adding max line counts and truncation. A solution could be found that > would appeal to all user of the various icon view features. I am sure this is true, but it's been four years since I raised the issue, so it seems difficult to get the key people to make it happen. Anything you can do to assist the process is most gratefully welcomed! Miles
Can anyone explain, why the alignment looks that strange when using pango ellipses? According to http://developer.gnome.org/doc/API/2.0/pango/pango-Layout-Objects.html#pango-layout-set-ellipsize <quote>...so they fit within the width of layout set with pango_layout_set_width(). </quote> shouldn't the icons whose label is being ellipsized claim the same width as the ones with short label text? Is this due to a pango bug? Also, is there already a pango feature request for multi-line ellipsization? This could be very useful for our use-case. Olaf
how long does it take before this stuff gets into nautilus? any options of getting it in the 2.19.1 svn? or put it in but turn it off by default.. in about 2 months this "bug" is in here for 5!!! years and still not committed.
I'll add a real reason for why the work has not been done so far. Because it's depends on bug 327996. Could someone change the depends to add this bugs number. Thanks. Some help is still welcome.
there are so many line functions specified here: http://developer.gnome.org/doc/API/2.0/pango/pango-Layout-Objects.html#pango-layout-set-ellipsize surely you can use a few to get the same results 2 lines... for example with: pango_layout_get_line_count and pango_layout_set_ellipsize so that you get the lines... grab line 2... truncate it... rebuild the complete text with 2 lines and return it... done
Gnome: Ten years of freedom; and you guys still don't have this _needed_ function build into gnome. Look at this issue for once and put it in 2.20!! For real!! this "bug" is well over 5 years old now and _still_ not fixed and every time i use gnome i miss this feature.
I'm usually friendly towards users who request features as I totally understand their perspective, but you're just a naughty person. This issue isn't as trivial as it sounds.
Adding dependency on bug 469313.
does this look good to you: http://img526.imageshack.us/img526/2039/screenshotqd4.png Sorry if you don't like the request but be realistic, it's 5 years old and still looking unpleasant.
Seeing how often files are named from generic to specific information (say, "Artist - Album - Title.ogg", "Author1Author2Author3-Year-Title.pdf", "SeriesName-Season-Episode.ogg" and how useful this order can be for sorting, truncating them would remove the most important information from the display - the information required to distinguish it from similar files. Personally, I'd rather move a file on the desktop a little if it overlaps another icon than having to mouse/keyboard to every file to find the one I need. Also, how should this handle file extensions? Not being able to easily distinguish between two versions of the same file with different formats would be pretty annoying, but with extensions getting longer ("doreallycoolstuff.gedit-plugin" and similar) displaying them would take even more space from the relevant parts of the filename.
So, after 5.5 years, can we now explore implementing any of the ideas suggested in this bug report? I notice that a dependency has been resolved.
Marking the old patch status as "needs-work".
Wow i'm glad that the dependencies are resolved for this one. And if i'm right (sure hope so) it means that only adding (to the "And the patch" patch): pango_layout_set_width(layout, 50); (best to make a gconf value of this one.. 50 is a example value) pango_layout_set_height(layout, 2); (gconf wouldn't be bad here) will resolve this well over 5 years old bug. than it will still have some issues like mouseclick, mouseover and just selected to be resolved but those can't take another 5 years to implement. Now all that's needed in the gnome nautilus desktop is a decent auto snapping grid (like the one XFCE has).
(In reply to comment #67) > Seeing how often files are named from generic to specific information (say, > "Artist - Album - Title.ogg", "Author1Author2Author3-Year-Title.pdf", > "SeriesName-Season-Episode.ogg" and how useful this order can be for sorting, > truncating them would remove the most important information from the display - > the information required to distinguish it from similar files. I disagree. With Windows, the truncated text expands on mouseover. I, personally, am perfectly happy with that method of seeing file details. Furthermore, I am asking for an OPTION to be able to emulate the regular grid layout of Windows. I am not trying to force this on anybody else. That's what options do. Why do I bother? 5.5 years and counting..........
*** Bug 422630 has been marked as a duplicate of this bug. ***
*** Bug 440330 has been marked as a duplicate of this bug. ***
Created attachment 116738 [details] [review] Prelimitary patch I totally understand your griefs and disappointment. However, this isn't as simple as we hoped, even with the new Pango features. For the brave of you, I attached a bug that makes the feature semi-functional. Issues to resolve: A) the auto layout code breaks when renaming a file to a file name which has more than 3 lines. It might be worked around by only considering the height of the first three lines in nautilus_icon_canvas_item_get_text_rectangle(), but this needs documentation and testing. B) the icon stacking breaks when selecting multiple files. The Z position of the icons depends on the order you select the files - i.e. whether the overlong text covers the icon below or vice versa depends on the selection order. An ugly work-around might be to always draw the icons with smaller y values after those with large y values, a real fix could be to always draw the icons before the text. However, I am not sure whether the current EelCanvas architecture allows this. I think this would require that we convert the NautilusCanvasItem to a EelCanvasGroup, use one canvas item for the text and another one for the icon, and use different Z stacking values for two items. This also requires that Z stacking is shared between all the EelCanvasGroups. I can not investigate this in detail ATM due to lack of time, though.
OK, I committed a patch to trunk based on the prelimitary patch. Large chunks of the layout code were slightly reworked - we now distinguish between the text dimensions used for the grid layout, and text dimensions for actually rendering the text. Whenever an icon is not selected, its will icon will be truncated to three lines, at least in text-below-icon mode: http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14480 Multilined text-besides-icon mode will be trickier to resolve, but I doubt many people still use it nowadays that we have a compact view. Closing, even though issue B) is not resolved. Feedback appreciated - please file new bug reports. Closing.
(In reply to comment #75) > Feedback appreciated - please file new bug reports. > > Closing. I look forward to being able to test this. Currently I am busy working on a project that requires Office 2007, so most of my day I am working with Windows. I want to thank you very much for working towards fixing this problem! I understand that layout code is challenging, especially when we have resizable icons to deal with. I am fairly sure that somewhere in this bug discussion I requested the ability to turn off resizable icons in order to make completely regular icon layout (grid) possible. It is not clear to me whether the behavior after your patch will be that the full filename shows up on mouseover events. Anyhow, thank you, thank you, thank you!!!
> It is not clear to me whether the behavior after your patch will be that the full filename shows up on mouseover events. Thanks for bringing up the proposal from comment 15 again. I just implemented it in trunk: http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14482
Just for reference: http://blogs.gnome.org/cneumair/2008/08/16/before-after/
Thanx a lot for making this feature in Nautilus! Roughly 6 years of patience is rewarding huh ^_^ This is fixed in time for Gnome 2.24 right?
I don't think this is an improvement usability wise. See comment 17 and 18 in http://blogs.gnome.org/cneumair/2008/08/16/before-after/ . I'll cite them here for your convenience: # Adam Waldenberg Says: August 17th, 2008 at 2:19 am As someone with more experience working with usability issues (together with “nerds”) than most people, I can tell you that this change is probably more of a disadvantage than an advantage. If you are adding this change because it “looks crappy” the other way, you are doing it for all the wrong reasons. This solution will add excise, meaning users will have to take additional steps to be able to see the filename. Maybe the solution is more suited for the “Compact View” mode instead? This could maybe belong better there as the idea of a compact view gets pretty screwed up with long filenames and the old solution. Maybe. It still adds the same problems though. The majority of users will probably not appreciate this as the default behaviour… The users hanging around your blog (or on bugzilla) are not “normal & average” human beings. Always think about who will use nautilus other than the nerds and hardcore users. Bottom line… This doesn’t seem to add any usability advantage. So usability-wize its a regression. All of this is ofcourse just a guess…. But it is well based one. If you did some real user tests, people would probably choose information and information correctness over grid symmetry. Good luck :) # Martin Says: August 17th, 2008 at 12:32 pm I’m in complete agreement with Adam. Information completeness is more important to users than grid symmetry in this case. How about enabling this only in compact mode? When it comes to the desktop, perhaps you could detect if the filename of a file overlaps another icon and if so, ellipsize it. Or maybe not allow placing an icon so its filename overlaps.
I disagree. Imho this behaviour is present and widely accepted and appreciated (especially among 'non-nerdy' users) in most file browsers out there (including Windows and Mac OS). So why should nautilus be different here? My guessing is, that especially 'non-nerdy' users are easily confused by too long filenames as it's too much information at once. After all, this is how M$ does it and they know what John Doe needs to be happy. But I think, we can all be happy, if we make this feature optional. Then we just have to fight about whether it should be enabled by default or not.
I vote for having options, but having defaults very similar to those used in Windows and OS/X. Saying that users cannot cope with these defaults is just not true. But, if you have a usability lab and can run scientific tests to determine what people like and what makes them most productive, please test away.
This is a crap fix to a stupid bug. Most of the time you have a whacking great icon (which mostly conveys very little information) taking up 3 lines and in order to maintain a regular grid, the solution is to truncate the file name. Why truncate it by removing the end? Why not remove letters from the middle or the front, or just a random selection? Who are you to decide which parts of the filename are important to represent on this truncated view? 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. >in most file browsers out there (including >Windows and Mac OS). So why should nautilus be different here? "Because this is how windows does it" is NOT NOT NOT an even remotely valid reason for implementing a bug. Please people, use some imagination. Most people don't produce massive amounts of data, and for them it doesn't really matter that the filename gets truncated, as its still unique. The problem comes for those people that do produce lots of data, and a problem it is.
Please calm down. (Usability is difficult. And yes, Windows and Mac OS have many usability deficiencies and far to often Free and Open Source software just blindly copies what they do.) I think a reasonable solution is to always enable ellipsizing in compact mode and for the Desktop, automatically detect when filenames overlap and only ellipsize if they do. Christian (and other Nautilus maintainers), what do you think? Is this possible?
(In reply to comment #83) > This is a crap fix to a stupid bug. I stopped reading your message after your first sentence. This is not the way to discuss things. JFYI, http://live.gnome.org/CodeOfConduct states: | Be respectful and considerate: Disagreement is no excuse | for poor behaviour or personal attacks. Remember that a | community where people feel uncomfortable is not a | productive one. I know the CoC is just a set of guidelines, not rules, but it would still be helpful if you read this.
> I stopped reading your message after your first sentence. This is not the way > to discuss things. I apologise if you disagree with the language or you took offence in any way to the post. I'll rephrase: This is a poor fix to a more subtle bug than is originally described. I didn't intend any personal attacks and I hope the content to my post can be read on its points rather than its perceived slight (which is completely unintended). I am truly appreciative of the work put into Gnome, I just wish to see it be the best it can be. Peace all! Sorry for the noise.
I don't know what all the fuzz is about. The bug has been a bug for almost 6 years now. You guys had your time to discuss about its meaningfulness. Now that it's fixed, some people seem to go crazy about it. There is no way we will be able to make everybody happy here, since some people find this feature an enhancement to usability and some don't. I just think it would be very sad and unfair to the developers not to use this feature now that it has been implemented. Finally, if we aim to make it optional, the people who don't like this feature can still switch back to the original behavior. Can't we all just agree on that?
The reason nobody has commented on this bug until now was because they weren't aware it even existed. Those that argue this is not a bug are not likely to go searching for what they consider not a bug. The problem with this bug is that it preempts the solution, ie, the report is not solution neutral. The real problem here is that long filenames are poorly presented in the icon view. A good solution would satisfy all the use cases, including those that really do make use of long filenames. Please don't get my opposition confused with not wanting the problem to be solved. I just think that arbitrarily truncating the filename is not the solution.
We will add a preference for disabling the feature, and for defining the number of lines to which the text will be shortened. I agree that file extensions should not be ellipsized away - I am currently discussing with Behdad whether Pango allows it. As I mentioned: Please file issues in new bug reports. Martin (comment 84): > for the Desktop, automatically detect when filenames overlap and only ellipsize if they do. This is a great idea, however it's not easily doable as of writing. Maybe until then, ellipsization should be disabled for the Desktop.