Re: Sharing the places sidebar between Nautilus and GTK+

[Alexander Larsson <alexl redhat com>]

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

Yeah, i see no reason for this kind of setup at all. If we have real
widgets for each row then all dynamic behaviour can be handled by each
row-widget rather than having to be triggered by the model and then
having some view propagate the new value for something into the row
widget.

All we need is a gtk container widget that sorts its children by some
property (and uses notify::property signal to cause a resort). Then all
the magic involved with updating the ui as things change can be fully
implemented in the row widgets. Then we just need a way to enumerate and
produce row widgets for each type of data, and a way to get signaled
when new rows should be added.

> 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? 

On the other hand, we need a fileselector on unix and there is none, so
we must have *something*. And its while the sidebars may be different
they will not be vastly so, since we use a common base in GVfs.

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

Also, it makes it very very hard to do things like custom preview
widgets. I don't think this is really doable...