GNOME Bugzilla – Bug 689768
In listview mode, the UI background can not be clicked to serve as an interactive action area
Last modified: 2018-06-06 12:06:41 UTC
In listview mode, when browsing a folder with many entries, right click always selects the folder/file even if mouse pointer is over a "blank" area. As result, there is no way to get context menu for the current folder. This bug remained unsolved in Nautilus for many years until the function "gtk_tree_view_is_blank_at_pos()" was created in tree_view GTK component. Ubuntu 12.04 and 12.10 were released without the bug, but it returned in Nautilus 3.7 and I'm afraid that it can be present in Ubuntu 13.04 again. Using the function "gtk_tree_view_is_blank_at_pos()" is possible for Nautilus identify if the point clicked is over a file or folder name and take different actions. Old (fixed) bug: https://bugzilla.gnome.org/show_bug.cgi?id=94618
Correction: the bug was detected in Nautilus 3.6.3, not 3.7
What specific action were you trying to get in that context menu? The "gear" menu should have most of them.
For example: - new folder - new file - paste - properties - share It work fine in Nautilus 3.4 Theese actions must refer to current folder, not to a selected item inside it.
William Jon McCann, what information is missing to confirm this bug? Users lived with this for many bug before it is corrected. It will be unacceptable if this bug return to Nautilus.
All those items are available in the gear menu with the exception of share. Share is something that currently operates only on selections. Are you not seeing them there?
Ok, William, these options are showed in gear menu (except share), you're right. Maybe this bug should be closed and another be created with a more appropriate description. I can't understand why Nautilus need to have different behaviors from the same user action, depending on how items are displayed. In iconview mode, right click over an empty space shows folder options. In list view mode is impossible get the same response, if there are more than 20 or 25 files on it. I think the modes should be more consistent with each other and offer a more intuitive and standardized to users. There is no reason to select the item, if the right-clicked point is on an empty area, just as it happens in iconview mode.
(In reply to comment #6) > There is no reason to select the item, if the right-clicked point is on an > empty area, just as it happens in iconview mode. There is a reason. In icon view, empty space exists between different items. In list view, there is no space between different items. The space there is between details of the same item. As the whole row represents the same item, there should be no discontinuity. However, when there is a small number of items, there is actual "background" space bellow the list, which offers a background context menu as expected. The lack of this background space at the bottom of the list, when the number of items exceeds the available vertical space, is source to at least two more issues: - bug 651293, which is a very prominent issue, with a fair number of duplicates already; - bug 306413, which is valid again because the resolution of bug 94618 was reverted. [1] As a workaround to all three issues, I propose a 'dummy row' to be added to the end of the list, such that, if I scroll to the bottom, there is an empty space there. This 'dummy row' would offer a background context menu. It would also allow the floating statusbar not to obstruct the visibility of the last item on a list. [1] To be fair, one can simply drop on breadcrumb, but it's not as intuitive as dropping in-view.
You need to look at the problem from the user's point of view, not from the developer's. For the average user, a blank space is an empty area and when you click on this point the intention is not select an item, but hit the background. Create a dummy line at the end of the list, require the user to scroll to the end to get to use it, I think it's a bad solution, because you can have hundreds of files in the folder. Remember to click in the empty area is the only way to unselect an item. The solution to this problem adopted by Windows, MacOS, KDE and GNOME (previous version) is the best, do not see why change something that is working well.
1. Background click is necessary to unselect a file; 2. Background click is available in iconview mode, so it is a doubtful behavior; 3. Users are accustomed to access context menu right clicking background in order to create folder, share folder, create file, etc.
*** Bug 696493 has been marked as a duplicate of this bug. ***
Dropping NEEDINFO status, as the questions from comment 2 and comment 5 have been answered.
*** Bug 702328 has been marked as a duplicate of this bug. ***
Please ignore this line from comment #7. It is wrong: > - bug 306413, which is valid again because the resolution of bug 94618 was > reverted. [1]
The gear menu indeed contains the context menu I was just looking for, but I found it so unintuitive that I thought it was a bug as well. (Hence why I found this bug report.)
*** Bug 715122 has been marked as a duplicate of this bug. ***
*** Bug 723816 has been marked as a duplicate of this bug. ***
*** Bug 739194 has been marked as a duplicate of this bug. ***
What seems the most relevant for me is to give the choice to the user (adding a checkbox in the preferences). As a spare solution, I think the 'dummy row' is the answer to all the problems highlighted by António Fernandes (which are quite annoying). [url=https://bugzilla.gnome.org/show_bug.cgi?id=689768#c7]Comment 7[/url] As William Jon McCann said, the options are present in the gear menu, so the user doesn't need a lot of blank space and it doesn't matter to scroll to the bottom a few times in life. But you NEED to make these options more visible because it is VERY unintuitive for people who used other OS/Desktop Managers for years. I didn't imagine for a second they could be elsewhere, until I found this bug report.
I didn't think about it sooner : The user needs a drag&drop feature in the parent folder. Maybe you should dissociate behiavours in case of a drag&drop from the normal ones.
This will be fixed if we implement the action bar. Sadly no other option is technically doable as for now.
*** Bug 748931 has been marked as a duplicate of this bug. ***
*** Bug 744161 has been marked as a duplicate of this bug. ***
Is there anything happening on this front? There is no way to paste a file into a folder using only the mouse. Dragging-and-dropping will just move it, if it's on the same filesystem :(
Not so far, action bar is a difficult design problem.
What if, and I'll open another ticket if you like any of those, we add the folder context to the breadcrumb or the tab. You van drag items to both so they do represent the folder. Right-clicking the breadcrumb has the meaning, I'd think.
(In reply to Mario Wenzel from comment #25) > What if, and I'll open another ticket if you like any of those, we add the > folder context to the breadcrumb or the tab. > > You van drag items to both so they do represent the folder. Right-clicking > the breadcrumb has the meaning, I'd think. The breadcumb solution doesn't sound too bad actually. The tab solution doesn't sound good because there is not always a tab opened, I believe most of users use a single tab setup. However, there is a little overlap with the toolbar menu since the context menu for the current folder has "New folder" which the toolbar menu also have, and now we will add "Select all", "Paste", and, if I'm not mistaken, this is wanted because of extensions right? So the extensions menu has to go also there, which is quite unfortunate. Worth a try, and check out with the designers, feel free to ask them on #gnome-design
> However, there is a little overlap with the toolbar menu since the context > menu for the current folder has "New folder" which the toolbar menu also > have, and now we will add "Select all", "Paste", and, if I'm not mistaken, > this is wanted because of extensions right? Well, maybe not. The "Select All" might as well be also in the context of any item, right? I select one. Selecting all "Neighbours" would be fitting there as well. I don't know what you mean for the extensions? I only have "New Folder", "Paste", "Select All", and "Properties". Properties we already have. Select all could be meaningful everywhere. New Folder we already have. So it might be enough to just add Paste.
Looking again at the comments, they were complaining the context menu it's not just right there, but it was instead on the gear menu. So seems adding it on the pathbar or toolbar menu is precisely what initially was this bug report complaining about. We cannot have a proper fix with the current tree view on the view itself. This needs to wait until the new views are in. The action bar would fix all of these though. So seems the latest solutions are not good either :( We should just put our effort on making the pathbar design work and/or the ListBox port to happen.
In the last sentence I meant action bar
Would you accept a patch that adds "paste" to the breadcrumbs (properties already is there...)? That would be the solution for at least my use case and I would think that this is very intuitive.
(In reply to Mario Wenzel from comment #30) > Would you accept a patch that adds "paste" to the breadcrumbs (properties > already is there...)? That would be the solution for at least my use case > and I would think that this is very intuitive. I'm afraid of adding something that has not been well though with the future designs, because in this case we will probably need to remove it once action bar or the new views are in place. Unfortunately removing things from Nautilus have proven to be quite difficult even if a more sound alternative is provided, so I would prefer a push on the right direction instead.
*** Bug 783491 has been marked as a duplicate of this bug. ***
Wanted to issue exact this (would be my first Gnome issue...): why not add an empty row (or some pixels 'padding' on the bottom) so 'we' can use the context menu there? I'm on Debian testing here... It shows 'Files 3.22.3' that IS nautilus isn't it? Where can I find the 'gear'-menu? I seem to to have it here?
> why not add an empty row (or some pixels 'padding' on the bottom) so 'we' can use the context menu there? Would be a bit of a hacky workaround, which does not fully solve the problem because it would only work when you are fully scrolled to the bottom, which is not really intuitively discoverable as an action area.
I challenge you all to create a new, blank file, while in list view on a very populated folder. I don't think it is possible, due to this bug. Seems like a major oversight, since blank file creation seems to be a common need for using a computer, and list view is a very popular view. The solution is just to add an empty row at the bottom of the folder. It's not a hack. It's what Windows has done for over a decade. It's a thing, I promise. It's simple. We need a blank space to right click. If you can't stomach having users scrolling down, put it on the left or the right, but we still need something. By the way this bug has been complained about since 2011 in various forms, so, it's time to make it happen. Another solution, which I've also seen before in OS's, is just right-clicking on the parent folder icon in the top address bar serves the same behavior as right clicking the blank space in a parent folder. Intuitively it's the same concept: parent folder context menu.
Thanks for the suggestions everybody. There was indeed a number of possible solutions to this bug. After many iterations, we have settled for a menu in the pathbar. This is mostly implemented in git master now. https://gitlab.gnome.org/GNOME/nautilus/issues/322#note_112903
This has been fixed in the development version, with a location menu in the pathbar, which has got a Paste action. The context menu is preserved but no longer required for this action. https://gitlab.gnome.org/GNOME/nautilus/issues/322#note_112903
*** Bug 751025 has been marked as a duplicate of this bug. ***