Developer Info

Brief Program Overview

Dillo is a browser purely written in C; that helps to make it very fast and produces a smaller binary file than what would be achieved with normal C++ code. The trade off is that inheritance gets more complex cause it must be implemented with C code. That's a bit scary at the very beginning, but is not as bad at it seems.

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!

Dillo's main libraries are gtk+ (gimp tool kit) for widgets and glib for almost everything else (as memory management). So, if you happen to be developing new code, please try to find what glib has to offer you, and use it. Needless to say, you must use g_malloc, g_free, g_realloc and friends.

Dillo's SW-techniques include threads, callbacks, signal driven IO (input/output) and an engine that takes care of file descriptor activity (including sockets). Ah, there's also a widget abstraction layer that serves as an internal ADT (abstract data type) to gtk+; It's called Dillo widget (Dw_ within function names).

Those parts are documented inside doc/ dir within the tarball.

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

Patching

Patching is very welcome. Specially if the patched bug comes from the bug-track engine. But beware, 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 30 minutes 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 standar. Just to keep our code clean, and to simplify the patch-reviewing task.
It fixes the problem and doesn't cover the symptoms.: Sometimes the problem itself lays in a deeper layer; 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 they're on dillo widget, send them to Sebastian, and everything else to me.
If your patch is small and you need to share it for advice, send it to the mailing list. If it's big, let the mailing list know and either set an URL with it, or email directly to interested people.

Contributing

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!

The bug-track engine

It explains its purpose by itself, go and take a look at it here.

USE IT!