On Wed, 07 Sep 2011 15:24:48 +0200 Alexander Larsson <[email protected]> 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 _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
