97 lines
3.5 KiB
Plaintext
97 lines
3.5 KiB
Plaintext
"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: https://dillo-browser.github.io/old/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 constructed 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)
|
|
|
|
|
|
|
|
|