"Eliminate the guesswork and quality goes up."                             -------                              DILLO                             -------   These  notes are written with a view to make it less hard, noteasier yet ;), to get into Dillo development.   When I first got into it, I was totally unaware of the browserinternals.  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 somedocumentation,  just  to make a less steep learning curve for newdevelopers.   --Jcid                            --------                            OVERVIEW                            --------   Dillo can be viewed as the sum of five main parts:   1.-  Dillo Widget: A custom widget, gtk+ based, that holds theneccesary 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/Outputengine  that  handles file descriptor activity, the cache acts asthe  main  abstraction  layer  between  rendering and networking.   Every  URL,  whether  cached  or  not, must be retrieved usinga_Cache_open_url   (Described   briefly   in   Cache.txt,  sourcecontained in cache.c).   IO is described in IO.txt (recommended), source in IO/.   3.-  The  HTML  parser: A streamed parser that joins the DilloWidget  and  the  Cache  functionality  to make browsing possible(Described in HtmlParser.txt, source mainly inside html.c).   4.-  Image  processing  code:  The  part  that  handles  imageretrieving,  decoding,  caching  and  displaying.  (Described  inImages.txt.   Sources:  image.c,  dw_image.c,  dicache.c,  gif.c,jpeg.c and png.c)   5.- The dpi framework: a gateway to interface the browser withexternal 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_Interface_entry_open_urlis  queried to do the job; it calls a_Nav_push (The highest levelURL  dispatcher); a_Nav_push updates current browsing history andcalls  Nav_open_url.  Nav_open_url closes all open connections bycalling  a_Interface_stop  and  a_Interface_stop,  and then callsa_Capi_open_url wich calls a_Cache_open_url (or the dpi module ifthis gateway is used).   If  Cache_search  hits  (due to a cached url :), the client isfed  with cached data, but if the URL isn't cached yet, a new CCC(Concomitant  Control Chain) is created and commited to fetch theURL.  Note  that  a_Cache_open_url will return the requested URL,whether cached or not.   The  next  CCC  link  is dinamically assigned by examining theURL's protocol. It can be:   a_Http_ccc   a_File_ccc   a_About_ccc   a_Plugin_ccc (not implemented yet)   If  we  have a HTTP URL, a_Http_ccc will succeed, and the httpmodule  will  be linked; it will create the proper HTTP query andlink the IO module to submit and deliver the answer.   Note  that  as the Content-type of the URL is not always knownin  advance, the answering branch decides where to dispatch it toupon HTTP header arrival.   What happens then?   Well,  the  html  parser  gets  fed,  and proper functions arecalled  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 functionsare  activated  and  idle  functions draw to screen what has beenprocessed.    (The process for images is described in Images.txt)