The Dillo Web Browser
Dillo
    Home
    Achieved Goals
    ChangeLog
    Screenshots
    Download
    Mailing List
    Art


Bug Track Engine
    Bug Track Intro
    View Current Entries
    Bug Insertion
    Volunteering


Developers
    New Developer Info
    CVS
    Naming&Coding Design
    Project Notes
    Authors


Links


Help


Hosted at:
No host :-(


 

* Best viewed with any browser

Project Notes for Developers

Last modified: [Aug 21, 2001]

Downloads

An interesting addition that's to be made is a download facility. Current code has all the required framework to implement it. Basically the save button functionality is to be reused by adding a save-link-as item to the right button popup-menu and (this part requires implementation), a new button would be added/activated in the toolbar: a downloads button.

When clicked it should report download activity on every download in progress.

It should be implemented with an interface very similar to current bookmarks, showing the filename, amount of retrieved data and expected size (if known). Also an abort button to the leftmost part would be appreciated ;).

Ah, there's a little detail with that: the "application/octet-stream" mime typed links should be attached to this download scheme. With the corresponding dialog: "Unknown type, octet-stream, do yo wish to download it?"

If someone reading this feels like implementing the GUI part of it, and feels a little scared with the internal handling, just drop me a note and I'll come with the required help or plain code for it. (I hope)

(five months have passed, and not a single volunteer!)

Plugins

This is an idea that maybe could be better understood if stated as "simple plugins". The fact is that our current rendering system, and its associated internal layers, is not ready for a full widget integrated and interactive system, but (here's the good part), a simple plugin scheme, very similar to the way CGIs work is possible; even more, it has worked before.

The idea is to communicate the browser and the plugin in a similar way to the browser and a web server.

This is a work in progress that's stalled, a lot of work is already done; it only waits for priorities to signal a restart.

Internationalization and Localization (i18n & l10n)

A lot had been discussed on this topic, and though not a high priority, current position is to wait for GTK+ to handle its strings in unicode (UTF-8), and after that, switch dillo from ISO-LATIN-1 to unicode by adding a translation layer, and let GTK+ do the rendering job with pango.

While waiting for GTK+ to be ready, the site will provide links to interim patches that may be contributed. We already have one for Japanese!

Note: this topic is not simple, if you want to study it with some detail, let me suggest:

  • Glibc's texinfo documentation on iconv().
  • http://developer.gnome.org/doc/whitepapers/gtki18n/index.html
  • http://www.pango.org/

HTML parsing policy

Our policy with HTML is not to try to render badly written HTML, ideally send a warning message, and not to crash!

If you want to understand why, please go to our site's [links] section, and read "The decommoditization of protocols" by Raph Levien.

Any HTML parsing patch, should be backed-up with the HTML-4.01 spec. (also available from the [links] section). Note that previous HTML specs could be considered too.

Authors page

There's not a deterministic algorithm for this yet, but beware that people credited for sending patches, start to appear at the fourth accepted patch (or equivalent work). OTOH patches are always credited in the ChangeLog.

Jorge.-
[Aug 21, 2001]