Developer Info

Brief Program Overview

Dillo is a browser written in C and C++. It uses FLTK as its base widget library and it has its own widget system called Dw.

We have some documentation collected here.

There’s also an internal library called dlib that provides a set of useful ADTs to Dillo. It is used extensively in the C part of the code. You may check dlib/dlib.h to get familiar with it.

Dillo’s SW-techniques include inheritance, templates, callbacks, signals, and an engine that takes care of file descriptor activity (including sockets).

Dillo internals are not of a simple nature. A Web browser is an inherently complex application. Just think of every thing that needs to be coordinated to get the job done. And at the very same time!

Now you know what you’ll face when digging inside the code!


Patching is very welcome, especially if the patched bug comes from the bug-track engine. But be aware that only high-quality patches will be accepted.

Dillo is following an evolving software model where every new version of it, should be better than the former one; there’s no place for unstable releases!

So, if you want to submit a patch, please make sure:

It passes a stress test

A stress test is a testing situation where you put the newly implemented routines under heavy workload (more than what’s expected under normal circumstances).

It passes your own custom testing functions

An alternative to the previous point. If the stress test is hard to implement, or if the new functionality is better covered with this kind of test, choose this way!

It follows Dillo’s Naming&Coding design

Every patch must strictly follow our coding standard in order to keep our code clean and simplify patch reviewing.

It fixes the problem and doesn’t cover the symptoms.

Sometimes the problem itself lies more deeply; take your time, investigate and fix it the right way.

You submit your patches following a “one bug, one patch” scheme.

Don’t submit a huge monolithic patch that fixes several things. Split it into smaller patches, one for each bug.

You strive for clean code, not for hacks.

Although it’s very cool to write fancy solutions, they are harder to understand and to maintain; please avoid them.

You let others know what you’re doing

Don’t do silent patching; use the bug-track engine, make a bug report and update your progress regularly. Ask for help if you need it.

Where to send patches

If your patch is small, send it to the mailing list. If it’s big, let the mailing list know and either email it to me, set an URL with it, or email directly to interested people.
Finally, please submit your patches with ‘hg diff‘.


If you’re planning to contribute and stay with the project as part of the development staff, please subscribe to the mailing list, and email me your expertise areas and interests; keep reviewing the bug-track engine and the Web site, participate, and have fun!