GNOME Bugzilla – Bug 164398
Column width is not saved in list view
Last modified: 2021-06-18 15:55:51 UTC
Nautilus seems to autosize the folders to the length of longest item. Most of the time this works great, but if a directory contains an unusally long filename, it can be cumbersome to navigate the dir at the size a person specified of the actual window for spatial nautilus. The user can either resize the name tab, or make the window larger. I choose to resize the name tab and expected it to stay the next time I was in that directory, but it resets to length of longest filename. If in the the future the users wants back default resizing behaviour, view/reset to defaults should take care of this. Also, it would be nice if this was on a tab by tab basis. So if a user resizes name, it will not change but the rest (size, type) would continue to autosize. Other information:
Actually just using this a bit more I think it's a little more clunky. Nautilus in list mode (spatial or browser) does set the length of the name,size columns to the longest file of the location of where you first opened nautilus. Every directory you select thereafter does not get automatically resized. So if I am navigating my home which has an unusually long file name, the name column gets set appropriately, but if I then go to say /var/log which has all it's file of very short names, the column still remains the length of where I first started nautilus. So I propose two things: 1) make it so it always resizes appropriately as a user navigates to other directories and not just the first directory open. 2) If the user overrides the default autosizing it remembers that for that specific directory but continues to auto resize for other directories until the user adjusts those as well. The default behaviour of autoresizing should be reset by reset view to defaults. So maybe this should be split in two different bugs with #2 being an enhancement but I believe #1 is a bug and would be the logical behaviour since it does auto resize columns on the first directory.
Ok, I did a little more testing and now I understand how this works. Nautilus was still making the name the size huge even though I moved/renamed my unusually long filenames. Then I realized, that in another directory I had been to in nautilus had an even longer filename, and sure enough, when I went to that directory the name size was the exact same length of my unusally long file in that directory that I had only been to once in nautilus. I can see the logic, make fields fit longest encountered filename, but to apply this size globally and make the user have to manually readjust the lengths each time is klunky. Well, it will keep the user adjustments for that session, and as long as they stay in the same mode (list mode, icon mode). If a user goes to a directory where they specified icons, and then go back to a dir where they have it in list mode, it will autoresize again to the largest file length encountered regardless if that file is actually in the current dir. Please change this behaviour. I'm constantly resizing them. Just make it auto resize tailored to each directory, not the longest it encountered somewhere that the user might never go there again. AND, if the user manually adjusts it, remember those values until the user resets to defaults.
Am I totally off base with the problem I'm describing? Maybe something like even 'yeah this is not the functionality desired in nautilus' if thats the case.
"menu length of toolbar menu items" ... are you speaking about how large are the columns?
Yes, I'm actually speaking of the length of the actual column titles. eg. name, size, type, date modified etc. As I mentioned above, I found the length to get get really long if you visit a directory with a long filename. I've now tried a distro with 2.10 gnome so it's seems slightly different. If I launch nautilus and go to home which has all short filenames, the name column is manageable. But if I go to another directory that has a ridiculously long filename it auto adjusts name to that length of the longest name. Fair enough, but if I then go back to home it still uses this really long name column length, so then I start adjusting them. I'm saying it should autoadjust the length of the columns each time when visiting directories so the column are always just long enough.
In addition, of course it should do this for all columns, just using name as an example as it's usually the column most affected.
I'm not sure than changing to column size on every folder is a good idea
Please explain. Because as is, when i first launch nautilus in my home directory which at this time has short file names, the name column is sized just right (so auto resizing) to the length of them. Then when I go to a directory with a long file name it's again auto resized to it's longest filename. BUT, when I go back to home it retains the length of the last folder I just visited which was unusually long. So in the above senario, auto resize does happen but only for longer files, just not for shorter. I'm saying do it in all circumstances, not just as it encounters longer filenames.
And to add to this, as is, auto resizing half way (i.e. only when nautilus encounters longer filenames) is what annoys me. So either do it all the time (encounters large and then smaller file names, it resizes) or give me an option to not do it at all. I'd love an option to check that says 'let me size all columns and then they'd stay that way no matter what directory i go into' Now, this suggestion would concur with what you just posted as you say autoresizing is not a good idea. I'm just saying do it all the time or not at all.
right, that's an issue
Thank you. I hope an option to turn off resizing entirely would be added as well. Maybe even something in gconf at least. Not sure if this would be a seperate feature request.
Seems like this is a list view issue. Changing title and component accordingly.
*** Bug 410361 has been marked as a duplicate of this bug. ***
Patch available in https://bugzilla.gnome.org/show_bug.cgi?id=410361#c33 .
*** Bug 557081 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.