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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list