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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Sharing the places sidebar between Nautilus and GTK+
Hi Jannis,
On Wed, 2011-09-07 at 01:53 +0200, Jannis Pohlmann wrote:
> To be honest, I think we can do better than this. The user experience
> offered by the current places sidebar is far from ideal IMHO. In
> Nautilus 3.x
>
> * the sidebar has no mount/eject progress indicators,
> * the eject buttons do not look/feel clickable, i.e., they don't
> change their appearance on hover events,
[ This should have been fixed now if you use a recent enough GTK+ and
Nautilus ]
> I realize that, aside from the code still being somewhat rough and
> imcomplete, this is nothing we'd want to stuff into GTK+. In
> particular, faking the look of a tree view with custom widgets may seem
> like a hack to most people (even though standard GTK+ drawing routines
> are used). On the other hand it is fun to use and shows how the places
> sidebar *could* work IMHO:
>
> * progress indicators for async operations,
> * real mount/eject/cancel buttons ('cuz spinners alone are not
> enough),
> * individual row/button highlighting on hover,
> * keyboard navigation works (even switching between rows and
> buttons is possible),
I agree with these points, even if some of those might be possible to
implement with cell renderers and a tree view; to me, another added
bonus of not using a GtkTreeView but a custom container and a separate
widget for each row is it allows themes to easily style different rows,
which is used e.g. in the Documents mockup [1] and might not be very
easy to do otherwise.
[1]
http://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/documents/documents-sidebar.png
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On Sep 12, 2011, at 9:15 PM, John Ralls wrote: > > I rebased a local branch off quartz-integration against master and carefully > went through all of the changes. There were indeed a couple that didn't have > bugs, so I created the bugs and attached the relevant patches. There were > some others that were quite old, so I updated the patches on the bugs. That's great! Much appreciated. Now that I seem to have GtkTreeModelFilter under control, I will move back again to Quartz review. thanks, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On Sep 7, 2011, at 7:26 AM, Federico Mena Quintero wrote:
> Now, on technical matters:
>
> I looked quickly at "git diff origin/master..origin/quartz-integration"
> and the diff is very simple:
>
> * A bunch of changes to gdk-quartz and gtk*-quartz.c - I imagine that
> these can be merged just as they are, since they don't touch the
> platform-independent code at all. I'm sure some of these bits could be
> reviewed / prettified by someone who knows a lot of OSX idioms, but it's
> better to have them in *now* and polish them later.
>
> * This bit:
>
> --- a/gdk/x11/gdkdevicemanager-xi2.c
> +++ b/gdk/x11/gdkdevicemanager-xi2.c
> @@ -417,10 +417,6 @@ gdk_x11_device_manager_xi2_constructed (GObject *object)
> for (i = 0; i < ndevices; i++)
>{
> dev = &info[i];
> -
> - if (!dev->enabled)
> - continue;
> -
> add_device (device_manager, dev, FALSE);
>
> No idea what that's about.
Not mine, likely due to my having turned off the nightly merges/builds/pushes
until this matter gets sorted.
>
> * Some Makefile.am changes; these could use a quick sanity check.
>
> * Some additions to gtkprivate.h, analogous to what it has for win32 right
> now.
>
> * A bunch of "#ifndef GDK_WINDOWING_QUARTZ" in gtkselection.c, so that
> those functions can be implemented in gtkselection-quartz.c instead.
> This can probably be made prettier by moving the original functions to a
> gtkselection-x11.c or something like that.
Or I could duplicate the whole file, as was done with gtkdnd-quartz.c and
gtkclipboard-quartz.c. I prefer not to do that because any maintenance on the
primary file will cause problems unless it's quickly noticed and the
quartz-specific file is also updated.
There's a larger problem with this, though, worthy of its own thread: Compile
time OS/GDK_WINDOWING checks break the multiple-backend architecture of Gtk3.
Quartz is the worst offender, but there are "ifdef OS_WIN32" blocks floating
around too.
>
> * An unused variable in gtkthemingengine.c; should be removed.
>
> * Inconsequential whitespace changes in some .po files; should be
> removed.
More out-of-sync-with-master differences.
>
> * A tests/testundecorated.c - no idea.
Related to a crash in Lion with undecorated windows. See bug 655079. There's no
patch to add this to master; I'm not sure whether or not it should be. The fix
has already been committed to master and backported to 2.24, and the bug closed.
>
> In all, it sounds like you could merge all the changes to *quartz*.[ch]
> files as they are, and just give a quick look to the rest of the
> changes.
>
> As to what is in Bugzilla, is there a quick way to find all the Quartz
> bugs to speed up their review? (Or are those patches already in the
> quartz-integration branch? I didn't look at individual commits to see
> if they had bug numbers.)
I rebased a local branch off quartz-integration against master and carefully
went through all of the changes. There were indeed a couple that didn't have
bugs, so I created the bugs and attached the relevant patches. There were some
others that were quite old, so I updated the patches on the bugs. The bugs in
question are:
514843: gtkfilechooser should be more robust
571582: GtkSelection implementation for quartz.
628936: Minimal change to pass introspection.
657770: Write releaseed memory in gtkdnd-quartz.c
607115: _gtk_key_hash_lookup fails to handle modifiers
658722: Drag and Drop sometimes stops working
658767: Drag and Drop NSEvent is Racy
658772: Directory paths for resource directories are hard coded.
Regards,
John Ralls
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
