"Eliminate the guesswork and quality goes up."


                             -------
                              DILLO
                             -------

   These  notes are written with a view to make it less hard, not
easier yet ;), to get into Dillo development.
   When I first got into it, I was totally unaware of the browser
internals.  Now  that  I've made my way deep into the core of it,
(we  rewrote it 90% and modified the rest), is time to write some
documentation,  just  to make a less steep learning curve for new
developers.

   --Jcid



                            --------
                            OVERVIEW
                            --------

   Dillo can be viewed as the sum of five main parts:

   1.- Dillo Widget: A custom widget, FLTK-based, that holds the
necessary data structures and mechanisms for graphical rendering.
(Described in Dw*.txt, dw*.c files among the sources.)

   2.-  Dillo Cache: Integrated with a signal driven Input/Output
engine  that  handles file descriptor activity, the cache acts as
the  main  abstraction  layer  between  rendering and networking.
   Every  URL,  whether  cached  or  not, must be retrieved using
a_Capi_open_url   (Described   briefly   in   Cache.txt,  source
contained in capi.c).
   IO is described in IO.txt (recommended), source in src/IO/.

   3.-  The  HTML  parser: A streamed parser that joins the Dillo
Widget  and  the  Cache  functionality  to make browsing possible
(Described in HtmlParser.txt, source mainly inside html.cc).

   4.-  Image  processing  code:  The  part  that  handles  image
retrieval,  decoding,  caching  and  displaying.  (Described  in
Images.txt.   Sources:  image.c,  dw/image.cc,  dicache.c,  gif.c,
jpeg.c and png.c)

   5.- The dpi framework: a gateway to interface the browser with
external programs (Example: the bookmarks server plugin).
Dpi spec: http://www.dillo.org/dpi1.html


                      -------------------------
                      HOW IS THE PAGE RENDERED?
                      -------------------------

(A short description of the internal function calling process)

   When  the  user requests a new URL, a_UIcmd_open_url
is  queried to do the job; it calls a_Nav_push (The highest level
URL  dispatcher); a_Nav_push updates current browsing history and
calls  Nav_open_url.  Nav_open_url closes all open connections by
calling  a_Bw_stop_clients,  and then calls
a_Capi_open_url which calls a_Cache_open_url (or the dpi module if
this gateway is used).

   If  Cache_entry_search  hits  (due to a cached url :), the client is
fed  with cached data, but if the URL isn't cached yet, a new CCC
(Concomitant  Control Chain) is created and committed to fetch the
URL.

   The  next  CCC  link  is dynamically assigned by examining the
URL's protocol. It can be a_Http_ccc or a_Dpi_ccc.

   If  we  have an HTTP URL, a_Http_ccc will succeed, and the http
module  will  be linked; it will create the proper HTTP query and
link the IO module to submit and deliver the answer.

   Note  that  as the Content-Type of the URL is not always known
in  advance, the answering branch decides where to dispatch it to
upon HTTP header arrival.


   What happens then?

   Well,  the  html  parser  gets  fed,  and proper functions are
called  for  each tag (to parse and call the appropriate methods)
and the whole page is contructed in a streamed way.
   Somewhere  in  the  middle of it, resize and repaint functions
are  activated  and  idle  functions draw to screen what has been
processed.

   (The process for images is described in Images.txt)