GNOME Bugzilla – Bug 131259
Allow nautilus callers to specify a file to focus on
Last modified: 2011-06-27 23:48:14 UTC
Currently you can call nautilus with a URI and it will open a window showing that folder. It would be good to go a step further and allow specification of a file within that folder to scroll to and select by default. This could be used, e.g., by File Roller to bring up a newly unzipped file / set of files selected in Nautilus. Its also useful for Epiphany to be able to focus Nautilus on a just downloaded file.
Bug 328124 is a duplicate of this bug, and now nautilus shows an error dialog while before it just opened the folder without selecting the file, which was better behaviour.
*** Bug 328124 has been marked as a duplicate of this bug. ***
Created attachment 118418 [details] [review] Patch to fix bug Hi, the patch is working well in my tests, both in spatial and browser window.
Hi Nelson, thanks for the patch! I'm afraid that the use of g_file_query_file_type is not right there, as that function does blocking I/O, and could lock the whole Nautilus for quite some time if you try to open e.g. a remote URI. You should use g_file_query_info_async instead, and query for G_FILE_ATTRIBUTE_STANDARD_TYPE. Another solution, but the code can become more convoluted, can be wrapping the call to g_file_query_file_type in a I/O thread with the machinery that GIO offers (see documentation for g_io_scheduler_push_job).
Cosimo is right. I also think that we should have distinct binary calling syntaxes for * show a folder * reveal a file Maybe we should have a “--show-as-selection” parameter, which groups the incoming URIs by parent folders, and shows each of them with the specified appropriate selections. That way, an application or script that acted on multiple files could call nautilus --show-as-selection file:///home/foo/bar.zip file:///home/foo/foobar.rar
(In reply to comment #5) > Cosimo is right. I also think that we should have distinct binary calling > syntaxes for > * show a folder > * reveal a file > Maybe we should have a “--show-as-selection” parameter, which groups the > incoming URIs by parent folders, and shows each of them with the specified > appropriate selections. > > That way, an application or script that acted on multiple files could call > nautilus --show-as-selection file:///home/foo/bar.zip > file:///home/foo/foobar.rar > I have re-made my patch using g_file_query_info_async().., but you're asking here for more features, what about doing them without new commandline switches like.. nautilus \ file:///home/foo/file.doc file:///home/foo/my pics/ file:///home/foo/docs/1.doc file:///home/foo/docs/2.doc file:///home/foo/docs/3.doc would open 3 windows, first showing "file.doc" highlighted, second showing folder "my pics", and third showing "1.doc","2.doc","3.doc" highlighted..
Created attachment 118562 [details] [review] Patch using g_file_query_info_async As said, this is my patch using g_file_query_info_async. Will try to look at adding the other switches..
> I have re-made my patch using g_file_query_info_async() Thanks. > you're asking here for more features, what about doing them without new commandline switches Without any command line switch, how would you reveal a folder as selection?
(In reply to comment #8) > > I have re-made my patch using g_file_query_info_async() > > Thanks. > > > you're asking here for more features, what about doing them without new commandline switches > > Without any command line switch, how would you reveal a folder as selection? > I personally don't see how an external program would need a "reveal folder" option, moreover I see the whole "reveal" option like the weak brother of a "select" option, I mean, 90% of callers would choose "select" over "reveal" because their purpose is that the user can notice some file/folder over the other ones. That's right what "select" does. I haven't seen enhacement requests in bugzilla for "reveal" commandline option but for "selected" (this bug). Although bugzilla is not complete reflect of user's need it's some guidance. I'm adding to my patch the --show-as-selected option you mentioned, because current approach can't select a folder (it's opened instead) and can't select more than one file in the same folder.. I can also add later the "reveal" option if you think it's needed.
> 90% of callers would choose "select" over "reveal" Actually, by “reveal” I meant “select”, i.e. what you are proposing and what you implemented, just with a command-line switch, and for multiple files at once. I agree that scrolling to a file without highlighting it doesn't make sense. Looks like we had a misunderstanding here.
(In reply to comment #10) > > 90% of callers would choose "select" over "reveal" > > Actually, by “reveal” I meant “select”, i.e. what you are proposing and > what you implemented, just with a command-line switch, and for multiple files > at once. I agree that scrolling to a file without highlighting it doesn't make > sense. > > Looks like we had a misunderstanding here. > Ok, sorry, my misunderstanding comes from the fact that nautilus has functions to reveal and functions to select files in icon view, so I thought you were talking about that revealing.. anyway I will post an updated patch by monday, have a good weekend!
Created attachment 118941 [details] [review] Updated patch This new patch adds the --show-as-selection option, you can use it in conjunction with existing uri option, so for example: nautilus \ -s /home/nelson/dir1/file1.c \ -s /home/nelson/dir1 \ -s /home/nelson/dir1/file2.c \ /home/nelson/other_dir will open 4 windows: "/home/nelson/dir1" with fil1.c and file2.c selected "/home/nelson" with dir1 selected "/home/nelson/other_dir" showing the contents of other_dir Also if you just want to select one file, you can use default nautilus uri as well: nautilus /home/nelson/dir1/file1.c /home/nelson/dir2/file2.c will open two windows with file1.c and file2.c selected in each one.
(In reply to comment #12) > Created an attachment (id=118941) [edit] > Updated patch > > This new patch adds the --show-as-selection option, you can use it in > conjunction with existing uri option, so for example: > nautilus \ > -s /home/nelson/dir1/file1.c \ > -s /home/nelson/dir1 \ > -s /home/nelson/dir1/file2.c \ > /home/nelson/other_dir > > will open 4 windows: I meant 3 windows not 4.. Also, all window opening is done with g_file_query_info_async ()..
*** Bug 339332 has been marked as a duplicate of this bug. ***
Patch needs to be updated to support libunique as we dropped the CORBA usage in NautilusApplication.
Created attachment 143473 [details] [review] Patch that hooks up with the window_go_to infrastructure Here's another approach that uses the current infrastructure to open a location. This changes the behavior both from command line without switches and the Open Location dialog and checks if the path entered isn't a directory and if so, opens the parent of the file and selects the file inside. Comments?
Marcus: I agree with others in this bug that having such magical behaviour isn't right. The semantics of it is such that you can't express the "select a folder icon in the parent folder". What we need to do is finish the dbus API for nautilus scripting, and then use this API instead of the libunique stuff for the more complex commandline switches (in fact, maybe replace libunique totally?). Christian Neumair is working on such a dbus API atm.
*** Bug 600211 has been marked as a duplicate of this bug. ***
*** Bug 609413 has been marked as a duplicate of this bug. ***
*** Bug 619624 has been marked as a duplicate of this bug. ***
*** Bug 339565 has been marked as a duplicate of this bug. ***
*** Bug 612795 has been marked as a duplicate of this bug. ***
*** Bug 610408 has been marked as a duplicate of this bug. ***
Review of attachment 143473 [details] [review]: Marking as rejected because of Alex comment.
This bug was fixed here: https://bugzilla.gnome.org/show_bug.cgi?id=632427
*** This bug has been marked as a duplicate of bug 632427 ***