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