Re: Sharing the places sidebar between Nautilus and GTK+

[Alexander Larsson <alexl redhat com>]

On Wed, 2011-09-07 at 01:53 +0200, Jannis Pohlmann wrote:
> On Tue, 06 Sep 2011 17:44:01 -0500
> Federico Mena Quintero <federico gnome org> wrote:
> 
> > Hi, everyone,
> > 
> > There is a patch in [1], by Jon McCann, to make the shortcuts bar in
> > GtkFileChooser be pretty much the same as the one in Nautilus.
> > 
> > Rather than patch the wobbly edifice that is gtkfilechooserdefault.c,
> > this sounds like the perfect time to actually pull out the shortcuts
> > bar as a public class of its own, that is shared by both the file
> > chooser and Nautilus.
> > 
> > My plan is this:
> > 
> > 1. Copy nautilus-places-sidebar.[ch] into the GTK+ sources.
> 
> 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, 
>   * and the categories are a bit messed up (e.g. I have a few disks in
>     "Computer", other in "Devices"; mounted archives pop up in
>     "Network") and so on.
> 
> Of course, some of these missing features are due to cell renderer
> limitations, e.g. last time I tried, I couldn't get hover-in/hover-out
> events for individual cells to work good enough to implement a
> fully-working button renderer. But still, the places sidebar has more
> potential and the current implement feels somewhat half-baked.
> 
> For Thunar, I'm currently working on a widget to replace the
> GtkTreeView in the sidebar:
> 
>   http://mocha.xfce.org/~jannis/screenshots/xfce/thunar-shortcuts-pane-custom-20110604-1.png
> 
> This sidebar consists of four classes (ThunarShortcutsModel
> and ThunarShortcut for modeling the data, the custom widgets
> ThunarShortcutsView and ThunarShortcutRow for representing the view
> with its rows). You can already check out the current state here:

I agree that these things would all be nice to have, and I don't
necessarily think that it is a bad idea to just not use the list view
for this. It doesn't really act or look much like traditional listviews
anyway, nor is it typically large enough that we can't just instantiate
normal widgets for all the entries in it. I'm all for that.

I'm not sold on having a complex view-model separation for the
underlying data like you imply above though, but I didn't really look
much at the code.

There is also the issue of look and behaviour. From a quick look at the
screenshot thunar seems pretty similar to nautilus, but I'm pretty sure
we can find places where they diverge. We would need to agree then which
behaviour to pick and be forever bound to that (or at least to agree on
further changes).


> 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).

I don't think this is the right way. We should define new style classes
and what not for the parts we require, then the themes should be made to
theme them to look like they want (which incidentally may be somewhat
like treeviews).

> I guess what I'm trying to say is... if you merge something like the
> places sidebar into GTK+ (as part of the public API), don't just take
> the existing sidebar as it is; please improve it to make really useful.
> I'd be happy to drop our sidebar if there's a good one in GTK+ (and if
> there's anything I can do to help with that, let me know).

I agree.