Re: [Galeon-devel] Galeon feature implementation

Hi all,

I'm going to stick to replying to Ricardo's message to expand on my
previous words; mostly because the rest of this thread has unfortunately
degraded into an arguement over whether to have the feature or not,
which *is not* the matter at hand. I'm seeking ideas for optimal
implementation, that is what usability is all about right?

Ricardo Fernández Pascual wrote:
> Sorry for not replying before, but I am having lot of real work these
> days and real life is distracting me. 
> 
> Also, I was a bit unmotivated after the last round of discussions. I
> need to find some new motivation.

I understand perfectly; My lack of participation in past weeks has
similar roots. I hope I can sustain my current level of momemtum :-)

>>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.
> 
> 
> I think that the best place for those items is the Settings menu,
> because it is the most obvious choice... but I agree with you.

Well, I personally have no problems with a Settings menu, but as I said,
if the usabiity folks can suggest more optimal locations for these
items, I'll be happy to go with them.

>>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.
> 
> 
> I don't use the external downloader and our internal downloader works
> very well for small files. So, I don't care.

My attitude is much as Elivind has already articulated. Comprehensive
download features are rightly beyond the scope of galeon, so the ability
to easily hand off download tasks to a specialised program is a big plus
for me.

>>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.
> 
> 
> I think it would be enough if shift+click (or something else) always
> saved to disk without asking anything. 

The main concern with this is the shift+click is *not* equivlant to left
click because the left click does a full evaluation of the url which
might be something like sourceforge that churns, redirects and finally
sends a file down the pipe while shift+click just sends the url as is
to the saving method and you end up saving a webpage which contains a
link to the file you want. whoops. If we can make shift+click emulate
the full left-click behaviour except that it sets a 'I want to save
this' flag that surpresses the 'what do you want to do' dialog, this
would be acceptable, and avoid local action persistence. I'm not sure
how to do this as yet but I'm sure we can find a creative way.

> 
>>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.
> 
> 
> No usability issue here as far as I know. Maybe it is not for the
> default toolbar, but there should be a new button. Unfortunately, it
> required to be a control to be as useful as in galeon 1 (bonoboui).

Yeah, I didn't realise that you landed the simple new button just before
1.3.0 released. As you say, with Michael's work we should be able to get
a full feature new button.

> 
>>h) Gesture support. Not a lot to say here; we need prefs to turn it
>>on and off.
> 
> 
> I don't care about gestures anymore. I don't know why I ported them in
> the first place, because I don't use them. I'm not going to maintain
> that code, so unless someone wants to take care of it, it should be
> removed.

I believe that tko is currently fiddling with the gesture code. If he's
willing to maintain it, then we're fine; he'll need to speak up on that.
I do agree that unmaintained gesture code would be bad.

> 
>>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.
> 
> 
> Thanks to Michael. I need to look at it, but don't know when.

Thanks to Michael again! And to you ric for looking after this.
Final comment as with Elivind, the multiple reload behaviours are
mutually exclusive and will not 'just work' without an appropriate
telepathic interface; never right click, you never see it.

> 
> Nobody has convinced me still why can't we have two prefs dialogs. Gconf
> makes it very easy, and an advanced dialog would allow us to make a very
> easy to use simple dialog.
> 
> I know that the word "Advanced" is tabu these days.

I completely agree here, but I am reliably informed that things won't go
so well if we just do what I want. :-) So, I ask for the expert opinion
on how this can be reconciled.

Hopefully some of you are more creative than I and help keep everyone
happy,

--phil