Re: Sharing the places sidebar between Nautilus and GTK+

Hi Federico,

Generally, this sounds like a good plan to me. I have some comments
below.

On Tue, 2011-09-06 at 17:44 -0500, Federico Mena Quintero wrote:

[...]

> 4. See what common, public interfaces we need.  For example,
> 
>   nautilus_window_set_initiated_unmount (sidebar->window, TRUE);
> 
> seems like it could be replaced with a signal on the GtkPlacesSidebar
> class, and then Nautilus can start a spinner or whatever when an unmount
> operation starts.  Another common interface would be something like
> gtk_places_sidebar_select_path (sidebar, "file:///foo/selected") to
> highlight a particular item.

IIRC nautilus_window_set_initiated_unmount() is basically a hack to
redirect a specific NautilusWindow to $HOME instead of closing it when
it's opened at a mount location and the mount disappears as a
consequence of being unmounted from inside the same window (as there can
be multiple windows in Nautilus pointing to a mount at the same time),
so probably this is not something useful to replicate in the
single-window GtkFileChooser.

> 5. See what nautilus-isms *should* be doable with plain GIO, and see if
> there is anything else that Nautilus needs to do about them via signals;
> maybe for something like
> 
>   nautilus_file_operations_mount_volume_full (NULL, volume,
>                                               volume_mounted_cb,
>                                               G_OBJECT (sidebar));

As far as I remember, the only thing that those nautilus wrappers add to
using plain GIO is checking for trash files on the mounted volumes (and
prompting to the user a dialog asking if the trash should be emptied
before unmounting if so).

> 6. See what things should be available or not in the file chooser...
> when dropping files on the shortcuts bar, Nautilus can do
> 
>   nautilus_file_operations_copy_move (uris, NULL, drop_uri,
>                                       real_action, GTK_WIDGET (tree_view),
>                                       NULL, NULL);
> 
> 
> Same thing for
> 
>   nautilus_file_operations_empty_trash (GTK_WIDGET (sidebar->window));

So, first of all we should think about whether this kind of interactions
are desirable in a file chooser. I don't think GtkFileChooser should be
a full-fledged file manager, so I would just disable e.g. copy/move
while porting code to GTK+.

On the other hand, other operations like emptying the trash might make
sense and exposing them in GTK+ currently means either copying a lot of
file operations code from Nautilus into GTK+, or using the DBus
org.gnome.Nautilus.FileOperations interface as Alexander suggested.

[ I think what I would love to see in my dreams for this is a stateful
file operations stack in GIO, allowing to have a central GTK+ UI to
display completed/ongoing transfers and notifications embedded in the
shell (to be used e.g. for browser/IM file transfers as well), but it
looks like a lot of work :) ]

> One little caveat: that part of Nautilus is GPL, and GTK+ is LGPL,
> although it *seems* that the places sidebar code may initially have come
> from GTK+ and then reworked heavily.  I haven't checked the history
> closely.  What do we do about this?

The git history suggests the initial code for the sidebar was
contributed by Jamie McCracken, but it doesn't mention whether it comes
from GTK+ [1]. As far as my contribution to that code goes, it's fine
for me to relicense those parts to LGPL, but maybe we should ask the
other contributors as well.

[1]
http://git.gnome.org/browse/nautilus/commit/src/nautilus-places-sidebar.c?id=977c0f99380c111749b04c20b34113f635d1d0e7

Cheers,
Cosimo