[Usability]Galeon feature implementation

[Philip Langdale <philipl mail utexas edu>]

Hi all,

Following up a conversation some of us (unfortunately sans ricardo and 
yanko) had with jdub yesterday, I have been convinced to throw out my
list of desired features and behaviours to get usability input on
implementation. Whether marco's decision to resign as maintainer is a
permanent one, and we hope it isn't, this is still a valid area for
discussion.

As many of you are well aware, I have not been happy with the direction
that galeon2 is going in, and I've said so many times in a less than
constructive manner. jdub has convinced me that I shouldn't assume that
my goals are completely incompatible with the gnome2 paradigm. We'd
prefer to avoid any sort of plugin 'solution' and 'dump the feature'
would probably be unhelpful. So, with that in mind, I offer the
following for your consideration:

Features:

a) "Exit saving session", implemented as a File menu item in galeon 1.
I can't really see any other place to put this, but perhaps you can.

b) Equivalent functionality to the Settings menu. I am told that an
actual Settings menu isn't The Right Thing(tm) but as long as the
items under it end up in the menu structure at the end of the day, I'm
happy. In case you don't have galeon1 or are disinclined to look at it,
the settings menu provides quick access to filtering configuration and
toggles for such things are turning java and javascript on and off and
forcing the usage of user defined colors and fonts.

c) Java and Javascript Consoles. I simply hold a completely opposite
position to marco on these. I would assume they would live under the
Tools menu.

d) External Downloader support. Well, we had this until the very last
minute when marco commented it out... I'm not sure there's much of a UI
issue here. It's a matter of some prefs (dirty word, I know) to indicate
whether an external downloader is being used and what it is.

e) Ability to choose helper app for unhandled files rather than being
forced to use the gnome-vfs default. I have conceeded the point that we
shouldn't persist the user's choice of helper app. It was felt that this
was "creating our own mime database" which I'm not fully convinced of,
but it's less work eh? Nevertheless, I consider it completely
unacceptable to offer no choice and force the user to have to make a
persistent change in the gnome-vfs capplet outside of galeon just to
use xpdf for a stubborn file instead of ggv. My current view is that
this should be done by extending the "What do you want to do?" dialog
to allow the user to choose a helper from gnome-vfs's list. Simply
clicking on Open without giving the issue any thought would launch the
default helper as before.

f) As a related issue, I would however like the ability to persist the
decision to save to disk, so that files can be saved simply by clicking
on them without any other interaction. However, such persistence must
take place on a mimetype by mimetype basis which brings us back to
accusations of having our own mime db again. Creative ideas here would
be much appreciated.

g) A New button for the toolbar. I'm not sure whether there was a
usability argument behind it's absence or whether if was the crippled
nature of bonoboui toolbars. Now that we're getting traction on this,
allowing for middle and right click actions on buttons, we can do a
proper new button, I hope.

h) Gesture support. Not a lot to say here; we need prefs to turn it
on and off.

Behaviours:

a) Toolbar behaviour. Right click context menus for toolbar buttons as
with galeon1. History for back/forward/up as context menus and nice
things like the reload context menu offering reload all/bypass cache.
thanks to the bonoboui folks moving to make this possible, I think we
can make it happen.

b) Generally unconfigurable behaviour. I'm still unconvinced about
disposing of prefs, especially for highly idiosyncratic things such
as mouse scrolling behaviour. I don't belive there is such a thing as
a 'sensible default' in such cases. The best you can hope for is that
defaults reflect the habits of one developer and everyone else has to
make do as best they can. I'm not appreciative of programs that demand
the user conform to it when it could easily provide flexibility; I don't
want to be the one inflicting such a program.

I can probably come up with more, but I think this is enough for
starters.

I have no attachment to any particular UI implementation as long as the
features are present at the end of the day. I look forward to your
insights.

Thanks,

--phil