Hi, On Mon, 29 Sep 2003, Ringwraith wrote:

I'd first like to say thanks for Dillo, its sooo great loading the complete list of CPAN modules in less than 2 seconds, as compared with the nice 5 to 10 seconds with mozilla/firebird :)

Thanks. Is good to know you like it.

I do not know if this has been discussed but:

(yes, to some extent...)

One thing I noticed, as Dillo matures, it will obviously need a configuration/preferences menu. I am really starting to get pissed off (pardon lang) at how other browsers use the standard toolkit based widgets to do their configuration. This, IMHO, with the features of today's browsers, clutters up the user interface and causes bloat with the browser. I think having a PURE html interface to doing web browser configuration would do two important things:

1. Gives the flexibility to have a feature rich browser while maintain simplicity. It is a web browser, 90% of the user interface is a web page, so why not make the GUI something the user is familiar with.

2. Reduces bloat.

IMHO not so much importantly,

Very important for us.

3. Allows for nice customization (themes) of the user interface by someone who knows HTML and vi w/o having to recompile dillo. ;)

Well, the idea is very close to what you state (1 and 2, 3 as a plus).

I am considering to attempt to make a module for the configuration of Dillo that will do this:

1. Configure all aspect of the browser including the (upcoming?) plugin support.

Dpi is working now. We are polishing it with Ferdi to make it ready for the next release. It has been working for some time though. For instance the bookmarks plugin ships with 0.7.3.

2. Allow pluggable configuration. If plugins have any configurable options (sometimes they do), they will also be configurable using the interface.

This module would be accessed through something like:

config:// or about:config (i like config:// much better)

As of dpi naming is now, something like: dpi:/preferences/ or dpi:/prefs/ (most probably with a shortcut from some menu)

It would obviously have some security built in so that no one can pull a IE type trick on us and be able to do things they shouldn't.

Currently, dpi checks the request to come from dpi-generated pages...

Anyhow this is just a brainstorm, what are your thoughts on doing something like this?

To me it looks as if you haven't read the dpi docs, and used the dpi framework very much, but your thoughts are quite lined with what we are-doing/want-to-do! Please read doc/Dpid.txt, and play a while with bookmarks.dpi. That will give you a lot of background. With regard to preferences, I'd suggest to start by modifying simple bits first, and then to extend to a broader range. For instance you can try with an on-the-fly change of force_my_colors and later some other simple ones. Beware that the preferences parsing code needs some changes to avoid leaks and conflicts when run twice or more (it was designed with a single pass in mind). This is not hard to change though! Cheers Jorge.-