GNOME Bugzilla – Bug 498506
Add dbus interface for common file operations
Last modified: 2010-12-02 02:00:10 UTC
This would allow applications to better integrate with nautilus, eg. having nautilus-sendto be able to copy a file to a usb disk. Alex also mentioned: - opening new windows (rather than the Bonobo-using command-line interface) - copying/moving/deleting/moving to trash files (could be useful for applications like Rhythmbox that handle libraries of files) - selecting a specific file in a window (better "reveal in file manager" for download managers, file-roller) - "copying" a file (Edit -> Copy)
(In reply to comment #0) > - selecting a specific file in a window (better "reveal in file manager" for > download managers, file-roller) That's something that would be very nice in Epiphany. When auto-opening the download folder after download complete, we'd like to be able to put the downloaded file into view.
We over in the GNOME Do project would love this, and will buy who ever implements it a case of their favourite beverage.
*** Bug 547479 has been marked as a duplicate of this bug. ***
Also, requesting thumbnails without having to link to libgnome-desktop. I'd like that for the attachment UI in Evolution.
The Gloobus devs (a instant preview system for files in Gnome) would need this to reduce the number of shortcuts from 2 to 1 for preview. We thus would have a much needed equivalent to MacOS's Quickview.
Created attachment 145216 [details] [review] Added basic dbus interfaces to application and window Hi, I started adding dbus interfaces to nautilus. So far it's only for NautilusApplication and NautilusWindow. But I'm willing to add more, if people are interested. Further additions are also dependent on the help I'll get, since some things in Nautilus still confuse me ;-) Feedback is very welcome! Cheers
> I started adding dbus interfaces to nautilus. So far it's only for > NautilusApplication and NautilusWindow. But I'm willing to add more, if people > are interested. This is a good idea, thanks for your efforts. Actually, I started working towards the same functionality just a few hours ago. However, my approach was to add some code from Epiphany which handles the case where the D-Bus connection drops, and tries to reconnect afterwards (cf. src/ephy-dbus.[ch]). I also decided to put the D-Bus application, windows and views into separate objects (nautilus-dbus-*) because the concept we plan to expose slightly differs from the internal window, slot and view concept. A D-Bus view would map to a slot rather than a view, at least in the current design.
Comment on attachment 145216 [details] [review] Added basic dbus interfaces to application and window Patch needs a great deal of work before it could be accepted (generated code, bad formatting, fails to check errors, leaks GFiles and strings, open window should take a 'Screen' parameter rather than assuming the default, etc). Setting patch status as needs-work, but may be obsoleted by Christian's patch soon.
(In reply to comment #7) > also decided to put the D-Bus application, windows and views into separate > objects (nautilus-dbus-*) because the concept we plan to expose slightly > differs from the internal window, slot and view concept. A D-Bus view would map > to a slot rather than a view, at least in the current design. That's how I planned to do it, too. This simplifies nautilus interface fom a DBus perspective. So it totally makes sense to put it in separate classes. It's good to hear that you're working on it. It seemed to me before, that nobody followed up on this, although it was suggested several times. (In reply to comment #8) > (From update of attachment 145216 [details] [review]) > Patch needs a great deal of work before it could be accepted (generated code, > bad formatting, fails to check errors, leaks GFiles and strings, open window > should take a 'Screen' parameter rather than assuming the default, etc). That's right. The reason for submitting it in such an unfinished status was to demonstrate that I started working on it and that it works (hate to only talk about things). But I also submitted it so early, because I wanted to see if someone's already working on it. And as it turned out it is. > Setting patch status as needs-work, but may be obsoleted by Christian's patch > soon. Probability is very high, since Christian seems to have much more experience with Nautilus than I have and can accomplish it faster.
Created attachment 164147 [details] [review] Add support for copying files on the command-line
Note that it's not even compile-tested as my devel env is a couple of days too old :)
Created attachment 164324 [details] [review] Add support for copying files on the command-line
Review of attachment 164324 [details] [review]: I finally managed to review this :) Looks mostly fine, I inlined some comments below. ::: src/nautilus-application.c @@ +824,3 @@ } + + if (g_strcmp0 (name, COMMAND_COPY) == 0) { I'd merge this following code with COMMAND_OPEN, and then add an if block later to see if you should copy or open. @@ +859,3 @@ + } + + for (i = 0; urls[i+1] != NULL; i++) Missing curly braces around the for cycle declaration (here and in the for cycle below). ::: src/nautilus-main.c @@ +520,3 @@ + if (copy_uris && uris_array->len < 2) { + /* FIXME print out an error that we're missing + * arguments */ Could you please fix this FIXME? Or remove it completely, since you will warn out anyway later?
*** Bug 626479 has been marked as a duplicate of this bug. ***
*** Bug 497008 has been marked as a duplicate of this bug. ***
Cosimo, what's the plan wrt this patch? Should we: - use dbus-glib for it and fix the build? - port the existing patch to GDbus? - wait until GApplication is sorted (don't like this idea) - use libunique instead? Note that I'd also like that patch to include "empty-trash", with the possible confirmation dialogue.
(In reply to comment #16) > - port the existing patch to GDbus? I went for this, it allows a very easy extendibility. I committed to master a patch that implements a very basic FileOperations dbus interface, with just one method (for now), which is CopyURIs (as: source_uris, s: destination_uri). > Note that I'd also like that patch to include "empty-trash", with the possible > confirmation dialogue. It's indeed a good idea to add more operations to this interface, but I don't want to expose everything over the bus, so I'd like to hear some use cases first (which is yours for emptying the trash by the way?) I'd like to close this bug, which is old enough; I opened bug 636269 for the other request of this bug.
I read some use cases for EmptyTrash in the dependencies of this report, so I added that to master too.