Welcome to Dillo project!
- Dillo is a web browser project completely written in C.
- Dillo is small: source is less than 300 Kb, and the binary is around
- Dillo aims to be a multiplataform browser alternative that's small, stable,
developer-friendly, usable, fast, and extensible.
- Dillo is mainly based on GTK+ (GNOME is NOT required!)
- Dillo is a free-SW project in the terms of the GNU general public
- Current code uses gzilla-0.2.2's html-parser, and almost everything else
was rewritten from scratch!.
- Dillo is very fast!
[ Achieved goals ] -
[ ChangeLog ] -
[ Screenshots ] -
[ Download ] -
[ Mailing list ]
[ Bug-track engine ] -
[ Naming&Coding design ] -
[ Authors ] -
[ Project notes ] -
[ Links ] -
[ News ]
[ Art ] -
[ Help ]
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 just keep with the latest one:
Jan 29, 2002
Our primary concerns by now are:
Future Goals (these may change in the future)
- Keep moving a myriad of small, pending issues
- Review and test the Cookies patch
- Simple plugins (or external viewers/programs/handlers)
- Extend and improve the table code
That's enough work for now!
- Implement downloads, as described in the project notes
- Release the FTP plugin
- Add support for frames
- Implement redirection as rfc2616 suggests
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
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 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
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
- 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
If you're planning to contribute and stay with the project as part of the
development staff, please subscribe to the
mailing list, and
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