GNOME Bugzilla – Bug 693459
File name column truncated by wide columns
Last modified: 2015-06-08 14:15:04 UTC
Created attachment 235572 [details] screenshot As the attached screenshot illustrates...
Created attachment 242955 [details] [review] Ellipsize all columns They may be long strings such as the location column and will steal from the name column. We don't want that. All columns should be represented in the properties dialog in full anyway.
A related problem on Nautilus 3.8.1: The name column cannot be made wider if that would cause a horizontal scrollbar to appear. This means some file names are always cut off unless you make the window bigger - or, if it is already maximised, buy a bigger screen. The width should obviously be limited to the longest entry instead. Should I create a new bug for that?
FYI, my patch isn't quite right because some columns should probably have a fixed width. We'll need a lookup table of some kind to determine if the column should be ellipsized.
*** Bug 698673 has been marked as a duplicate of this bug. ***
Created attachment 252978 [details] [review] Make non-name columns resizeable smaller than their label Another issue is that columns could not be resized to be smaller than their label. This makes the label text into ellipsizable GtkLabels, and now column resizing works a lot more like it should. I think a full solution would create a horizontal scroll bar if a user expanded a column manually, but I don't know any of the details about how this works...
That's still an issue in 3.8 and make the list mode difficult to use with users with small screen (the name column ends up having only "..." entries for those users with no way to resize it)
For me is very important to see both the name and path of the file, and sometime the names and the paths are very long. I use 3 PCs (one is a netbook that I use travelling) with Ubuntu-Unity 13.04 and Nautulus 3.4.2 and I cannot do the upgrade to Ubuntu 13.10 because this issue in Nautulus 3.8. Must I look around for another file manager or leave Ubuntu? Please can you do something to make Nautilus usable again? I agree with the suggestion to create a horizontal scroll bar when the sum of the sizes of the columns is greater than the space available and let the width of all the columns more narrow than the label and/or the content (as it was up to 3.4)
*** Bug 721928 has been marked as a duplicate of this bug. ***
I commit to this bug. Status still "UNCONFIRMED"?? Hey maintainers! What the hell are you doing? 1) Badly configured "standard" column widths. 2) No possibility of resizing columns, if window-space is full-filled. (https://bugzilla.gnome.org/show_bug.cgi?id=693459) 3) and much more... Who tests the new bullshit you are programming? Do you no the meaning of "system-test"? No actions for simple bugs? No releases go out, it tests aren't passed!! Damned projects that wish to "re-write" an already working application, but can't comply to available features/functionality anymore. This making lives of users much worse than before. If your target is to have "mean to play the developer role", than please, at least prove that you are capable of that. We users, want to see working applications, which are worth to have. All efforts to create development opportunities for playful programmers are "no go" for the community. Whole Gnome 3 project prove that programmers has become unreliable, and future of IT-world is very dark...
Alex ("careca"), do you even realize that Nautilus has over one thousand bug reports open, some of which are more urgent than my own? Your comment is harmful to everybody involved and constitutes verbal abuse. Any more like that and I'm can pretty much guarantee you will be banned.
*** Bug 698017 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > FYI, my patch isn't quite right because some columns should probably have a > fixed width. We'll need a lookup table of some kind to determine if the column > should be ellipsized. What columns do you think should not be ellipsized?
Date-like, Size-like, Type-like columns I think.
And please, remember on: - correcting "horizontal scrool-bar" behavior. - save "standard" column width (per column). See windows "set/save folder view". - never "auto-resize" name-column (this "craps" views every time again). - saving width settings "per folder" (folders contained in history). - set history length. etc. Please, look at old nautilus project. IT WORKED quite FINE (with few exceptions). Furthermore, Give the user flexibility" to customize behavior. Please, change Status to CONFIRMED. Thanks
Changing a bug's status to confirmed won't make it magically fix itself. But here, let me do that, if it helps you stay polite & constructive.
Can I remind readers of the issue as reported? When using the "Search" option in Nautilus, if the search term contains (e.g.) one letter, the displayed results truncate the Name column to no more than a list of ellipses. This is regardless of the amount of space assigned to the overall Nautilus window. Additionally, the name column cannot be resized - the grab handles on the column header do not operate in "search" mode. Discussions over "which columns should/should not have ellipses" are irrelevant. If anyone is in any doubt, please take a look at the example screenshot from Jean-Francois. As it stands, the search feature is not usable by ordinary folk as they would not be able to see the list of returned filenames. My suggestion would be to retain the existing column sizes when the search feature is initiated. Sorry I'm not on the developer team - I'd love to have a crack at this (ability not withstanding :-) )
(In reply to comment #13) > Date-like, Size-like, Type-like columns I think. What about Permissions? (I'm not working on this now, just plotting.) (In reply to comment #16) > Discussions over "which columns should/should not have ellipses" are > irrelevant. It's very relevant because there are only three ways (that I can think of) to prevent the name column from shrinking too much when a new column is added: 1) Shrink other columns, not just the Name column. 2) Remove other columns. 3) Allow horizontal scrolling, as suggested by careca. Then you don't have to shrink anything. Currently, most of the space for the Location column (which appears during a search) and the Original Location column (which appears in the trash) is taken from the file name. By ellipsizing e.g. the location column, we allow much more room for the name if the location is long. We already "remove" the Modified column when performing a search or when entering the trash can (by not including that column in the list of columns that we use by default in a search or in the Trash). The only other columns displayed by default are Size and Type. I would argue that the Type column is never particularly useful and we could save a good chunk of space by not showing that by default, but others could argue that it does make sense to keep by default. I was going to say "I think it's safe to assume that horizontal scrolling will not be approved," but it looks like that already happens when the Location column gets really long. So not shrinking existing columns might be actually doable. But if we don't shrink existing columns, then the new column (Location) would not even be visible without horizontal scrolling, and that column really needs to be visible for you to have any chance of disambiguating between different folders with identical names, so this is probably not a desirable solution.
> I was going to say "I think it's safe to assume that horizontal scrolling will > not be approved," but it looks like that already happens when the Location > column gets really long. So not shrinking existing columns might be actually > doable. But if we don't shrink existing columns, then the new column (Location) > would not even be visible without horizontal scrolling, and that column really > needs to be visible for you to have any chance of disambiguating between > different folders with identical names, so this is probably not a desirable > solution. I think it's clear to anyone that the only solution that make sense is that with the horizontal scrolling. Otherwise it's a dog chasing it's own tail: if you shrink some column there will never be enought room for some other column. The user should be able to choose the width of each column in every view. It's not predictable wich column will be the one that need more room for it's content. Someone can have a short path deep and a very long filename with a very long common prefix (this often happens when dealing with Public Administration here in Italy) someone else on the other hand can have very long path and very short filename. Even worst these scenarios can be true at the same time (maybe I need long path in a Nautilus instance and a long filename in another instance on the same screen).
I completely agree. Thank you ZaZy for the clarity. I think that this is the only really good solution.
I agree with ZaZy. In addition to flexibility for all possible usercases (→ horizontal scrollbar), we also need reasonable defaults. If one of 200 files has a long file name (maybe a phrase, part of url, or a scientific reference), is it worth to extend the whole column to the full width, so that the user probably needs to downsize it again? If the file type column lists for all files a short type ("png", or "Image"), but vor one single file a monster string like "application/vnd.oasis.opendocument.presentation", should the default view extend the column to that width? If we force columns to fit to every string then we can get extreme cases that hinder usability. By default, we need something like a median, that ensures the user can recognize relevant information at first glance, and that the user can distinguish files. At the same time, all columns should be resizable to any width the user needs, even if it requires a horizontal scrollbar.
(In reply to comment #20) > I agree with ZaZy. > In addition to flexibility for all possible usercases (→ horizontal scrollbar), > we also need reasonable defaults. > If one of 200 files has a long file name (maybe a phrase, part of url, or a > scientific reference), is it worth to extend the whole column to the full > width, so that the user probably needs to downsize it again? > If the file type column lists for all files a short type ("png", or "Image"), > but vor one single file a monster string like > "application/vnd.oasis.opendocument.presentation", should the default view > extend the column to that width? If we force columns to fit to every string > then we can get extreme cases that hinder usability. > > By default, we need something like a median, that ensures the user can > recognize relevant information at first glance, and that the user can > distinguish files. > > At the same time, all columns should be resizable to any width the user needs, > even if it requires a horizontal scrollbar. Totally agree. The only workaround for me and for now is disabling some columns. Any ETA?
*** Bug 725840 has been marked as a duplicate of this bug. ***
*** Bug 726304 has been marked as a duplicate of this bug. ***
*** Bug 728680 has been marked as a duplicate of this bug. ***
This kind of problem seems to be happening in many applications. See: * https://bugs.launchpad.net/linuxmint/+bug/1267622 * https://github.com/linuxmint/nemo/issues/413 * https://bugzilla.redhat.com/show_bug.cgi?id=1037577 * https://bugs.launchpad.net/ubuntu/+source/baobab/+bug/1308322
Agreed on horizontal scrolling. When I grab a column divider and move it to the right, I'm saying "Make this column wider." Currently, if the pane is full horizontally, it ignores me. Not good. :-) Adding a horizontal scrollbar when I do that is infinitely preferable to ignoring what the user said to do.
I think Nautilus is excellent, but this column size issue is very annoying. Please, fix it soon.
*** Bug 733966 has been marked as a duplicate of this bug. ***
*** Bug 734008 has been marked as a duplicate of this bug. ***
This bug has been reported again as bug 732004, and we are happy to tell you that the problem has been fixed in the development version. It should be solved in the next major release. *** This bug has been marked as a duplicate of bug 732004 ***
Dear developers, I am not so sure the described bugs include the following weird behaviour. Please validate your solution against this procedure: Open Nautilus, click on the lens (search device). Type something in the search field like "virtualbox". It will find your files with that name. Click on the list icon, you get a list of files; the name column is wide enough to be read. The columns are resizeable (although, strangely, sometimes you get the grabbed borders move in the opposite direction) Get back to the search field, start deleting with the backspace key: Your search result might change, but until the search term length is 4 character ("virt") or more, name readability and column resize-ability remain same. Once the search term is 3 char long ("vir") or shorter, within half a second or so, the name column becomes unreadable, as it is ellipsized to three dots, and you cannot resize any of the columns any more. This makes the search unusable if your search term is short. And retyping a few more chars won't revert the situation to usability. Why the hell is that? Who did manage to think that a short search term should cause a different behaviour of column visualization? THIS IS CRAZY. (Even more strange: of course typing requires time, so the search term is always short at the beginning of your typing. But the weird behaviour starts only half a second after you have typed). There definitely seems there was some "intentional" if not "intelligent" thinking behind this behaviour! LAST BUT NOT LEAST: Why do we need to wait the next major release for the fix? Please simply remove any mechanisms which occurs based on the search term length. Thank youuuu!
Dear developers, I am not so sure the described bugs include the following weird behaviour. Please validate your solution against this procedure: Open Nautilus, click on the lens (search device). Type something in the search field like "virtualbox". It will find your files with that name. Click on the list icon, you get a list of files; the name column is wide enough to be read. The columns are resizeable (although, strangely, sometimes you get the grabbed borders move in the opposite direction) Get back to the search field, start deleting with the backspace key: Your search result might change, but until the search term length is 4 character ("virt") or more, name readability and column resize-ability remain same. Once the search term is 3 char long ("vir") or shorter, within half a second or so, the name column becomes unreadable, as it is ellipsized to three dots, and you cannot resize any of the columns any more. This makes the search unusable if your search term is short. And retyping a few more chars won't revert the situation to usability. You have to close the window. Why the hell is that? Who did manage to think that a short search term should cause a different behaviour of column visualization? THIS IS CRAZY. (Even more strange: of course typing requires time, so the search term is always short at the beginning of your typing. But the weird behaviour starts only half a second after you have typed). There definitely seems there was some "intentional" if not "intelligent" thinking behind this behaviour! LAST BUT NOT LEAST: Why do we need to wait the next major release for the fix? Please simply remove any mechanisms which occurs based on the search term length. Thank youuuu!
> Why the hell is that? Who did manage to think that a short search term > should cause a different behaviour of column visualization? THIS IS CRAZY. > If you think that is intentional, it won't be a bug =) > (Even more strange: of course typing requires time, so the search term is > always short at the beginning of your typing. But the weird behaviour starts > only half a second after you have typed). There definitely seems there was > some "intentional" if not "intelligent" thinking behind this behaviour! > yeah, a bug there probably by some heuristics in the size negotiation. > LAST BUT NOT LEAST: Why do we need to wait the next major release for the > fix? There is a fix on 3.16 that fix it almost entirely, although the size negotiation "bug" if any is still there. > Please simply remove any mechanisms which occurs based on the search term > length. > If it would be that simply, it would be already completely fixed.
lurix66 I reproduced step by step your procedure on my UbuntuGNOME 14.04.2 and everythihg worked flawlessly. Maybe it's relate to your specific distro or to some specific result obtained on your linux box.