Re: autocompletion

Jeff, you have successfully managed to avoid responding to my reply to
your email regarding galeon in gnome 2.2, despite your active
participation in our little autocomplete debacle.  In the absence of a
reply, you may have noted that I have checked in the helper chooser UI.
I still  have no idea how compatible this is with the feature freeze,
and whether such a freeze applies, as galeon is currently not in gnome
2.2. So, a reply on this subject would be much appreciated.

I wash my hands of the stupid autocomplete situation; I don't care
enough about it to fight the issue; I'll settle for being a second
class user poking about with gconf-editor. (Yes, Jeff, that does mean
the pref is going nowhere. I hope its sculking around in the depths
of gconf won't confuse any newbies or keep you up at night.)

With regard to the maintainership of the project, those lonely few of
us who are left need to have a proper discussion on the matter, though
I will now state for the record that I am willing to take on the
responsibility, though perhaps somewhat reluctantly; the status quo is
not sustainable in the long term, if for no other reason than we don't
really have anyone to put their foot down and say "This is a release".

Earl Killian's list of suggestions is rather ambitious; even mozilla
hasn't attempted a UI for such per-site functionality, it does remind
me that our personal information controls are currently very regressed.
We have no image management at all and the lack of a settings menu for
easy access to blocking functionality renders it largely unusable. In
addition, mozilla is capable of more finetuned cookie control than we
currently pass on to the user. This really does need to change.

On a more serious note, we are currently not using the mozilla security
manager to confirm URI loading when we should be. This is not too
serious in the sense that it would allow inappropriate script execution;
this is checked internally. However, there are certain situations where
particular URI loads should not be allowed. A remote frameset attempting
to populate a frame with a local file:// URI is such an example. Galeon
permits this when mozilla does not. How did we end up in this position?
The security checks were refactored out and are now conducted at a
higher level. Previously galeon didn't need to worry about them, now it
does.

--phil


Jeff Waugh wrote:
> 
> Anyway, there's a lot resting on the maintenance of Galeon. I would dearly
> love to see a *real* *GNOME* web browser shipping with GNOME - and the
> distros.
> 
> The distros don't want to support Mozilla - it is far too painful for "real
> users" to use (I'm not talking about newbies, I'm talking about people who
> use computers but don't really care about them). Look at the difference
> between Netscape and Mozilla - that's not done because AOL/Netscape are
> duffers... They know their market.
> 
> Right now, the best bet for major distributors (think Red Hat, Sun, etc) is
> Phoenix. It has the Mozilla project behind it, and they're working hard on a
> usable and slick browser based on Mozilla. That's annoying - I mean, Phoenix
> is great, but it's not Galeon!
> 
> I don't want Phoenix to win. I want Galeon to win.
> 
> - Jeff
> 



-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en