Re: [Usability] Toolbar flexibility ideas

[Alan Horkan <horkana maths tcd ie>]

On Fri, 1 Sep 2006, Shaun McCance wrote:

> On Fri, 2006-09-01 at 01:05 +0100, Alan Horkan wrote:

> > On Thu, 31 Aug 2006, Ronan Jouchet wrote:
> >
> > > Date: Thu, 31 Aug 2006 16:11:14 +0200
> > > From: Ronan Jouchet <r jouchet free fr>
> > > To: usability gnome org
> > > Subject: [Usability] Toolbar flexibility ideas
> > >
> > > Hi, I've 3 UI questions about possible flexibility improvements in
> > > GNOME/GTK UIs :
> > >
> > > - One of the things that I miss from some (Windows) apps is good toolbar
> > > customizability. Firefox/TBird also do a great job there with their
> > > customizable panels.
> >
> > > I thought that sort of feature wasn't planned in GNOME apps, but then I
> > > found one magic Evince dialog : Edit>Toolbar. Wow ! Ala-Firefox
> > > draggable items, separators, smooth animation, great !
> >
> > Abiword has customisable toolbars too, just so you know.

> There was talk of getting a toolbar editor into GTK+,
> but I don't know what came of it.  My guess is it's
> waiting on the long-standing request for a high-level
> application window widget.

Perhaps making it possible to rearrange icons/buttons on all gtk toolbars
would be a better medium term goal, than any kind of docking or toolbar
rearraning.  Once you can customize the toolbars like that there is not
much need to be able to put two toolbars horizontally end to end.

Closest relevant bug report I could find was this:
Bug 120645  Add a toolbar/menu editor
http://bugzilla.gnome.org/show_bug.cgi?id=120645

Unfortunately the toolbar editing behaviour in Epiphany is not the same as
the behaviour for moving items around the panel which would be very big
inconsistency to introduce to the whole toolkit.  One or the other would
need to change (my reflex action would be epiphany, more people do know
the panel).

What I'd really like is built in click tracking and usage analysis so that
when users choose to customize menus and toolbars they will have useful
information to help them decide.  (Think of the autohiding menus in
Microsoft Office only done properly, it would _never_ change anything
without asking but give you the information you need if you want to change
your menus and toolbars.)

> > > - In the same domain, why the "Detachable Toolbar" tickbox in
> > > System>Preferences>Menus&Toolbars is only effective on a few apps ?
> > > (e.g. Evolution yes, gedit no, Nautilus no)
> >
> > Many applications fail to implement this feature.
> > When gedit moved from an older type of Toolbar they dropped the feature
> > without thinking about it.
>
> To be more precise, this was a feature of the toolbars
> found in libbonoboui.  GTK+ toolbars never had this
> feature, and writing it oneself is non-trivial.  Thus,
> as more and more applications move away from bonobo,
> fewer and fewer applications have this feature.

I realise I am not as clear and precise as I should be on the techincal
details but I was primarily used to seeing it in Glade, where you needed
to first add the grab handle container and then put the toolbar inside.
I'm referring to the detachable toolbar feature specifically, I do realise
the ability to fully dock and rearrange toolbars was a much more
complicated feature only bonobo provided.

> Personally, I don't think this is a good candidate for a desktop-wide
> toggle.

There also used to be an option to make the menus detachable too.  When
that was removed I'm surprised the detachable toolbars didn't go with it.

Rather than removing the option immediately I would think the first step
would be to turn it off by default and restore some of the consistency
which has gradually been eroded.


> (It's certainly not something I would be inclined to add
> to Yelp, for instance.)

The fact that you would have to add it at all is really the problem
though.

> Individual applications should decide whether this is useful for their
> users, and allow users to toggle the feature in the toolbar editor
> dialog.

Realistically a lot of developers will take the path of least resistance
and not provide it.  If the toolkit provided the necessary systemwide
infrastructure and developers had to do little more than add a menu item
or two and enable a dialog then getting rid of the systemwide toggle could
make a lot more sense.


Sincerely

Alan Horkan

Inkscape http://inkscape.org
Abiword http://www.abisource.com
Open Clip Art http://OpenClipArt.org

Alan's Diary http://advogato.org/person/AlanHorkan/