Re: [PATCH] - New sidepanel plug-in for Gtk bookmarks and places

[Alexander Larsson <alexl redhat com>]

On Wed, 2005-06-29 at 12:25 +0100, Jamie McCracken wrote:
> Alexander Larsson wrote:
> 
> > 
> > I'm not really against having the bookmarks in the sidebar. That might
> > be a good idea. However, what I object to is adding yet another sidebar
> > which is very similar to an existing one. Adding the bookmarks to the
> > tree sidebar, separated by a horisontal line is easy. It would allow the
> > sort of use the places sidebar allows by default. It would also allow
> > other, more powerful uses, and wouldn't create more superfluous ui
> > elements. 
> 
> 
> So would it be okay to include extra built in bookmarks for the treeview 
> (IE Documents and Desktop - I would like the layout to match the 
> filechooser's) and can I remove the bold labels for the root elements 
> (they make it look ugly)?

I've been thinking some about this, and I think it can work. Lets ignore
the bold thing for now and discuss that later.

The behavour you want for the places part of the tree sidebar is:
* separator between the roots and the shortcuts
* Allow expansion of tree sidebars
* But, don't consider them "roots" when auto-expanding due to a location
change.
* Allow dnd of folders to the empty part of the sidebar, meaning "add
bookmark"

The main problem I can see with using the tree sidebar as a places
sidebar is that the tree auto-expands when you navigate the tree, thus
the shortcuts are almost always scrolled out of view.

I can see two main ways to solve this:
* Add a preference about auto-expansion on location change. (This really
makes sense as a preference, because it works with the way some use the
tree, but not with others.) It also solves a similar issue with the
auto-expansion of the tree hiding the mounted volumes below.
* Somehow split into two trees and pack the trees such that expanding
something in the volumes part never totally hides the shortcut part of
the tree.
I tried to figure out a way to do this, and it may be possible if you
have a custom container widget for the splitting and a slightly
customized GtkScrolledWindow that size_requests the full height of the
child. However, its not obvious how the splitting up should work (i.e.
in the case of both trees being tall, how should we split? 50% each?)
Another way would be to put the trees in a vpane and let the user change
the relative sizes.

I'm not sure this two-tree splitting is better than having it all in one
big tree. It gives you less prefs, and works for everyones use habits
without having to mess with prefs, but it uses more space, and you can't
get as much space for one of the trees as you can in the one-tree case.

OSX seems to go with the one-tree model, but then they don't allow the
trees to be expanded, and especially, they don't auto expand them. The
way they resize the shortcuts depending on how many there are makes it
clear that they assume there isn't gonna be a lot of them.

Maybe we could experiment a bit with the two approaches.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a hate-fuelled chivalrous cop searching for his wife's true killer. She's 
a blind winged politician with only herself to blame. They fight crime!