GNOME Bugzilla – Bug 330644
directory is not created in the folder it's meant to
Last modified: 2011-02-25 20:03:42 UTC
Please describe the problem: There's no way to create a directory in an unfolded subfolder, the new directory is always created in the view's root directory instead, no matter which one is highlighted. Steps to reproduce: 1. Unfold some sub-subfolders 2. highlight one subfolder 3. file->new dir or ctrl+shift+n Actual results: directory created in the view's root directory Expected results: should be created in the subdirectory Does this happen every time? every time Other information:
pasting something in such a subfolder does the same, it will be pasted into the view's root folder, not into the highlighted one
*** Bug 339179 has been marked as a duplicate of this bug. ***
Confirmed with Nautilus 2.14.3 on Ubuntu Dapper.
Ubuntu bug about a similar issue: https://launchpad.net/products/nautilus/+bug/61786 "When browsing nautilus in list view, it is not always easy to simply create new folders. The main issue i have come across is if a folder is full such that to display all the contents, a vertical scroller is required. In this case there is no 'empty space' to right click and select 'create folder'. The simplest way to remedy this in my opinion is to offer an option in the menu, when right clicking on a folder, to 'create folder in here' type option, similar to the 'paste into folder' option. ... say if the parent folder that you are browsing is /home/bob/. Bear in mind that you are browsing in list view. If you expand a folder, say 'pictures' within /home/bob/, in this case, for all intents and purposes you are browsing 'pictures'. However nautilus rightly thinks you are still in /home/bob/, so if you go file > create folder, a new folder is created in /home/bob/ rather than 'pictures'. So adding another option to the right-click menu, similar to the effect of 'paste into folder', but with the functionality to create a folder within a folder, would make sense in this case, and improve usability."
This problem is related 94618 I suppose
Isn't this a basic, visual issue that should be fixed quickly? I am not a GUI oriented guy so I just started to use Nautilus. But I am surprise that such an odd and visible behavior remains unresolved for up to 2 years. Anybody using Nautilus will eventually experience this bug and when compared to other OSs, Gnome based OSs such as Linux feel less polish because of it.
I agree , this made difficult the migration to Gnome of people coming from Windows. Windows always have the "create folder" or "Create File" options in the right-click menu.
THis has been irritating me for years now. Please prioritize adding "Create Folder" to the context menu of all items within directories, the target being the items' immediate parent directory.
From my comment in bug 597531: Given a tree structure in a list view as following, A B 1 2 3 a b c C Then, 1. Select "A", "Create XXX", new item is at same level as A, B, C 2. Select "B", "Create XXX", new item is at same level as A, B, C 3. Select "2", "Create XXX", new item is at same level as 1, 2, 3 4. Select "3", "Create XXX", new item is at same level as 1, 2, 3 5. Select "a", "Create XXX", new item is at same level as a, b, c
*** Bug 597531 has been marked as a duplicate of this bug. ***
*** Bug 602084 has been marked as a duplicate of this bug. ***
Created attachment 180271 [details] [review] Proposed patch Hi, looks like in master NautilusView::get_backing_uri (), which is used to pick the destination of a new folder / new file / make link / make launcher / paste operation, always returns the view's model, i.e., the root directory. The attached patch makes get_backing_uri () an overridable function of NautilusView. Now, NautilusIconView implements a copy of the original function, while NautilusListView is a bit smarter and if one directory is selected, its URI is returned. Tested, it fixes all the cases above (actually, I didn't check the make launcher operation...), and DND (another user of this function) seems to work as well. Please review.
> Created an attachment (id=180271) [details] [review] > Proposed patch [...] Note that the attached patch only fixes the behavior of CTRL+SHIFT+n and "File -> Create $foo". It does _not_ add new entries to the selected item's context menu. That's another issue -- certainly worth a new patch. I'll take a look into it.
Created attachment 180298 [details] [review] same patch, one debug call to printf less Same patch as above, now printf-free ;-)
Review of attachment 180298 [details] [review]: Thanks for the patch, I feel this could be a real improvement. Some comments about how the feature itself is implemented before looking at the code: - it should probably create items in the inner directory even in case the selection is not a directory itself, as it's just the selection that indicates how deep are we in the hierarchy, not if we're selecting a folder. - if we're selecting a directory, and it's not expanded, it shouldn't try to create a new item inside that directory, as there is no feedback of what's happening ::: src/nautilus-list-view.c @@ +2021,3 @@ + + directory = NULL; + if (tree_view_has_selection (list_view->details->tree_view)) { You can avoid this tree_view_has_selection() check here; just call _get_selection()...if the selection's length is zero, the view has no selection. ::: src/nautilus-view.c @@ +374,3 @@ + return EEL_CALL_METHOD_WITH_RETURN_VALUE + (NAUTILUS_VIEW_CLASS, view, + get_backing_uri, (view)); I feel the code would be cleaner if you had a default implementation here in NautilusView, with the old code. So you would have view->get_backing_uri = real_get_backing_uri (with the old code) icon_view->get_backing_uri = NULL; list_view->get_backing_uri = your custom new code. NautilusListView could then chain up to the parent (NautilusView's) implementation in case nothing relevant is selected.
Created attachment 180429 [details] [review] new patch
(In reply to comment #15) > - it should probably create items in the inner directory even in case the > selection is not a directory itself, as it's just the selection that indicates > how deep are we in the hierarchy, not if we're selecting a folder. Done. It also works for those pesky "(Empty)" text-only tree view nodes that appear as children of empty directories. The actual semantics are described in the patch. > - if we're selecting a directory, and it's not expanded, it shouldn't try to > create a new item inside that directory, as there is no feedback of what's > happening Done. > + directory = NULL; > + if (tree_view_has_selection (list_view->details->tree_view)) { > > You can avoid this tree_view_has_selection() check here; just call > _get_selection()...if the selection's length is zero, the view has no > selection. The new patch uses gtk_tree_view_get_selection -- because the nautilus_list_view_get_selection doesn't include non-filesystem items (such as the "(Empty)" nodes.) > So you would have > view->get_backing_uri = real_get_backing_uri (with the old code) > icon_view->get_backing_uri = NULL; > list_view->get_backing_uri = your custom new code. Done Now, the returned uri seems to be correct in all the cases I tested, however sometimes the list view gets corrupted while adding/removing files to some subdirectory. I don't really know what's going on, perhaps there's something horribly wrong with my patch, perhaps I'm violating some NautilusListView undocumented assumptions...
Appareantly the list view corruption is not related to my patch. See bug 642039.
Committed after I figured out the corruption you are referring to in your last comment, and with a minor tweak to apply to current master. Thank you very much for your patch.