GNOME Bugzilla – Bug 627443
Add an "Open containing folder" command
Last modified: 2010-09-13 19:32:43 UTC
Created attachment 168340 [details] [review] evince-open-containing-folder.diff For the background behind this feature, please read http://people.gnome.org/~federico/news-2010-06.html#hackweek This patchset adds an "Open Containing Folder" command to Evince's File menu, and a corresponding toolbar item called "Open Folder". When clicked, Evince will open Nautilus inside the folder where the current document lives. This is very useful when web-browsing. If you click on a PDF link, Evince will open. Very often, downloaded PDFs have silly names like "2010.pdf", "sigchi2010.pdf", "2954-3-5-234.pdf" - that are only meaningful to whoever created the PDF. Sometimes you would like to rename them, or to delete them immediately if they are not useful to you. In that case, you can click on Evince's "Open Containing Folder" and tweak the file to your liking. And in general, this command adds bidirectional navigation - you can use the file manager to dig down and open a PDF, and from Evince you can climb back up into the file system. While the blog post referenced above says that this command should be available from the window's titlebar, we don't have that infrastructure yet. In the meantime, a toolbar button works equally well. I promise to modify this to detect that infrastructure when it becomes available, and not clutter the toolbar in that case :)
For also selecting the file in the folder, see nautilus bug 131259 or bug 498506.
Thanks Robin, was about to mention the same bugs :)
Federico, what about having a more generic way of "Open Containing Folder", just like what you describe in your blog post, rather than adding a button to toolbars in all apps? With GNOME Shell, it should be easy to have this button in the application menu or in a custom window decoration, even without client-side decorations. I think generally, it would be very useful to know what documents an application is currently editing, and specifically in which window. GTK+ could allow exporting this information (e.g. via a X window property), and the Shell could use it in a standard way. Zeitgeist could also take advantage of this. Of course, this is much broader than the scope of this bug, but it's really the time to consider these foolish ideas!
(In reply to comment #3) > Federico, what about having a more generic way of "Open Containing Folder", > just like what you describe in your blog post, rather than adding a button to > toolbars in all apps? With GNOME Shell, it should be easy to have this button > in the application menu or in a custom window decoration, even without > client-side decorations. Yes, makes a lot of sense. I like the idea! > I think generally, it would be very useful to know what documents an > application is currently editing, and specifically in which window. GTK+ could > allow exporting this information (e.g. via a X window property), and the Shell > could use it in a standard way. Zeitgeist could also take advantage of this. Michal Hruby just pointed me to a discussion about exactly that: http://mail.gnome.org/archives/wm-spec-list/2010-June/msg00000.html I think you have homework for the weekend now, tra la la ;)
(In reply to comment #4) > Michal Hruby just pointed me to a discussion about exactly that: > http://mail.gnome.org/archives/wm-spec-list/2010-June/msg00000.html Yes, I had actually commented on this blog post. But the mail thread seems to have died prematurely, as often on this kind of subject. Since the list seems quite inactive, it would be nice retrying on XDG... > I think you have homework for the weekend now, tra la la ;) Sorry, I've already a nice TODO list, and I'm not that efficient to implement all my ideas! Thanks for the blog post, that will for sure help improving things.
Comment on attachment 168340 [details] [review] evince-open-containing-folder.diff Hey Federico, thanks for the patch, I like the idea. >+ { "FileOpenContainingFolder", GTK_STOCK_DIRECTORY, N_("Open Containing _Folder"), NULL, >+ N_("Show the folder which contains this file in the file manager"), >+ G_CALLBACK (ev_window_cmd_open_containing_folder) }, >+ { "FilePageSetup", GTK_STOCK_PAGE_SETUP, N_("Page Set_upâ¦"), NULL, >+ N_("Set up the page settings for printing"), >+ G_CALLBACK (ev_window_cmd_file_print_setup) }, FilePageSetup? I guess you are using an old evince version and forgot to remove this. >+ parent_uri = g_file_get_uri (parent); >+ if (parent_uri) { >+ GdkAppLaunchContext *ctx; >+ GError *error; >+ >+ ctx = gdk_app_launch_context_new (); >+ gdk_app_launch_context_set_display (ctx, gtk_widget_get_display (ev_window_widget)); >+ gdk_app_launch_context_set_screen (ctx, gtk_widget_get_screen (ev_window_widget)); >+ gdk_app_launch_context_set_timestamp (ctx, gtk_get_current_event_time ()); >+ gdk_app_launch_context_set_icon_name (ctx, "evince"); >+ >+ error = NULL; >+ if (!g_app_info_launch_default_for_uri (parent_uri, G_APP_LAUNCH_CONTEXT (ctx), &error)) { >+ ev_window_error_message (ev_window, error, _("Could not open the containing folder")); >+ g_error_free (error); >+ } I think we could use gtk_show_uri() which does mostly the same
Created attachment 170176 [details] [review] evince-open-containing-folder.diff Thanks for the review! You are right; I rebased the patch incorrectly and that FilePageSetup sneaked in. I removed that in this version and made it gtk_show_uri() --- the icon_name from using the raw launch context is not used in gnome-shell, anyway (gtk_show_uri() doesn't let you specify an icon).
Review of attachment 170176 [details] [review]: Looks good to me, feel free to push it (master branch only). Thanks!
Pushed to master as 1034436d36e173bbfa374c64f94371f0579d6ff6. Thanks :)