Re: Sharing the places sidebar between Nautilus and GTK+

[Jannis Pohlmann <jannis xfce org>]

On Wed, 07 Sep 2011 15:24:48 +0200
Alexander Larsson <alexl redhat com> wrote:

> On Wed, 2011-09-07 at 01:53 +0200, Jannis Pohlmann wrote:
> > 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.

Neither am I, actually. This separation only exists because it made
sense with the old sidebar. Now that file information is resolved
asynchronously in the background it's starting to become awkward to
keep model and view synchronized. (Our model not only contains the
GFile for each row, it also holds the volume, mount, ThunarFile and
whatnot.) This is the part that I don't really like and I'm considering
to just drop the model entirely.

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

Yep, that's a problem. ;)

Its hard to predict the future of entirely unrelated pieces of
software from different projects, so maybe forcing a uniform UI for
this makes little sense at all? 

Here's a stupid idea: wouldn't it be possible to drop the file chooser
dialog entirely and have different file managers implement certain
D-Bus methods to show their own flavors of file and directory choosers
whenever GTK+ needs them? (Perhaps this could be implemented in the
form of a file chooser extension point, as is done in GIO, and
different desktop environments could ship individual implementations
for this.)

Again, this is probably stupid as the file chooser is so important to
GTK+ that we don't want to risk setups where no extension is available
and an error dialog pops up instead of a file chooser...

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

Sure. (Although, all it uses is a gtk_paint_flat_box() call. Anyway, I
get what you mean.) 

  - Jannis