GNOME Bugzilla – Bug 410361
persist column sizes
Last modified: 2012-08-14 02:56:51 UTC
[See http://mail.gnome.org/archives/nautilus-list/2007-February/msg00046.html and follow-up] At least for spatial windows in list view mode, nautilus should persist and restore the treeview column sizes when the user resizes them.
This appears to be a regression compared to 2.16.
Alexander Larsson mentioned in my blog comments that the need for this is more obvious now because " What changed is that ellipsation was enabled for the name column. This changes the size allocation of the tree view. " Personally I think that the ellipsation change has introduced this annoying bug and it should be reverted if it can't be fixed.
Why was the ellipsation change made in the first place? Is there a bug or -devel thread where the decision was made?
That bug was bug 408155; see also http://mail.gnome.org/archives/nautilus-list/2007-February/msg00038.html and http://mail.gnome.org/archives/nautilus-list/2007-February/msg00046.html. Since the column size is not persisted in nautilus 2.16 either (tested on edgy), I don't think this bug has anything to do with the ellipsisation patch.
> I don't think this bug has anything to do with the ellipsisation patch. This bug has become more critical due to the elllipsisation patch, which indirectly changed the allocation size of the window.
Created attachment 85472 [details] [review] Patch to fix column resize issues While this patch doesn't actually fix #410361, it handles the more important (or annoying) bug of the name column always being too small. I think that this is a decent interim fix - something needs to be done though, this bug makes GNOME look ridiculous. This patch makes the name column big enough to fit most file names, as well as causing the column sizes to be recalculated when files are bulk added (ie when the view is initially populated).
The gtk_tree_view_columns_autosize call doesn't seem to do anything at all. fm_list_view_end_file_changes is called on the end of each file change, and yet the columns didn't change at all. The original behaviour wrt name column sizing is that it was made initially the width of the longest name, but when you changed the size to something smaller it just cut off the text. Changing it to ellipsized changed things so that it didn't initially size to the longest name, but instead some small default value. So I added the longer width of 16 chars. I'll bump it to a larger value since a lot of people seem to think 16 is to small. I dunno if it is possible to get the original behaviour with ellipsation, but if we implemented persisted column sizes that is perhaps not a problem.
40 seemed a bit much. I made it 32 instead.
*** Bug 422285 has been marked as a duplicate of this bug. ***
I find 32 really to small If you have some music files on your drive. I would suggest 64. Maybe we should make a gconf key for it? But I guess it is a temporary problem? Problem in GTK or in Nautilus code?
Hmph. Ellipsisation seems to have taken something that did the right thing (whatever length your filenames are, you can read them, along with the extension and when I renamed files, the name remained visible) and replaced it with something that almost always does the wrong thing (something that is be too big for some set of filenames, too small for many other sets of filenames).
i second that. The current behaviour of nautilus is the worst a user can think of. What the situation even makes more bad is in older releases someone could double click on the column border in the header and the column would have become as big as the largest file name in that directory. This also doesn´t work any more.
I can also confirm that under Ubuntu Feisty 7.04 (nautilus 2.18.1) this is still present. IMHO this bug shouldn't be tagged as an 'enhancement' since nautilus shipped in GNOME 2.16 and even 2.14 didn't have this issue. Regards
FYI Debian unstable changelog: Source: nautilus Binary: libnautilus-extension-dev libnautilus-extension1 nautilus-data nautilus-dbg nautilus Architecture: source amd64 all Version: 2.18.1-2 . . * 12_list-view_expand.patch: make the filename column expandable instead of setting the width by default. Reverts upstream commit 12779.
I would like to remember to the introdutional request "At least for spatial windows in list view mode, nautilus should persist and restore the treeview column sizes when the user resizes them." As far as I understand the previous discussion the patches and changes provided so far do not repair this. Am I right? I think this would be very important for a "comfortable" feeling in Nautilus. See also http://bugzilla.gnome.org/show_bug.cgi?id=418307 .
Here is a semi complete list of duplicates: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/94014 https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/89031 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422563 http://bugzilla.gnome.org/show_bug.cgi?id=419343 http://bugzilla.gnome.org/show_bug.cgi?id=410361 http://bugzilla.gnome.org/show_bug.cgi?id=416628 http://bugzilla.gnome.org/show_bug.cgi?id=318725
In Debian we apply the patch in bug#419343 which partly fixes the issue, but it also requires the one in bug#316087 to work correctly.
The original column autosize behaviour is back for now, please see my comment in bug 419343. And yes, we should persist the column sizes..
*** Bug 47806 has been marked as a duplicate of this bug. ***
Duplicate bug #47806 (an old one yep!) has an interesting discussion about this issue.
*** Bug 418307 has been marked as a duplicate of this bug. ***
Patch no longer applies. Setting patch status.
*** Bug 561147 has been marked as a duplicate of this bug. ***
This bug in particular has been to much of a PITA to me to ditch nautilus completly. So devs feel free to ignore the common user request as documented here as you have been doing for so long but it wont hinder me anymore in my daily work.
I registered an account here just so I can say that this is a bug that severely needs fixing. It's hard to believe that this bug STILL has not been fixed! Gnome devs, I appreciate your hard work. But I am working hard to get everyone I know to switch over to Linux. It's hard to defend Gnome when new Linux users are coming to me with issues like this. Should I switch to KDE? Please fix this bug. Cheers for all your hard work!
(In reply to comment #27) > In fact I'm currently switching to kde. It's sad for me, after so many years of > using gnome. But certainly it's frustating to report bugs and ideas, and to > receive no answer from developers most of times. > > I can understand that all the proposals can't be implemented. But at least we > could receive some words saying "Hey, that's a good idea, but I'm very busy > with xxxxxxxx for now" or "Be sure your proposal won't be implemented while I'm > alive" ;-) or something. > > I think that receiving silent as the response to the effort of reporting bugs > and ideas, many of them evident (like the one in this thread), is not the way > to create a participative community to build a better software. I'm thinking now that I should just try and fix this bug myself. FOSS is about doing things yourself. My spare time is limited at the moment, but perhaps I should roll up my sleeves and try to fix this eight year old bug.
Note that the expander column approach, which was reverted in trunk because of a bug in GTK+ (fixed in the meantime), still fixes 90% of the issue. http://patch-tracker.debian.org/patch/series/view/nautilus/2.26.3-1/12_list-view_expand.patch
*** Bug 605940 has been marked as a duplicate of this bug. ***
Three and a half years. Amazing. I really do appreciate the work the devs do, but this is a bit ridiculous.
Created attachment 192024 [details] [review] Use an expander column for list view We still apply the patch with nautilus 3.0. Here is the updated version.
I can understand people wanting to see this bug fixed. However, please do not pollute the bugreport. I'm not a developer and no matter how much time I have I cannot help fix this bug. However, I do have the ability to clean up bugzilla from pollution. This is what I've just had to do. Note that GNOME Bugzilla is a developer tool. This is the last I'll say on this subject.
Could anyone at least review the proposed patch? It’s been in Debian for more than 4 years, and I don’t consider nautilus to be usable without it.
*** Bug 467417 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 164398 ***