On Wed, 2011-09-07 at 16:31 +0200, Jannis Pohlmann wrote: > On Wed, 07 Sep 2011 15:24:48 +0200 > Alexander Larsson <al...@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... _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list