

This project attempts to build up a special version of the web browsing
component of the KDE browser Konqueror (in particular its html rendering 
engine khtml and its io subsystem) . This version is supposed to run
on the Qt/Embedded platform for embedded devices, in an environment
without a KDE installation or a X windowing system, as one static
binary, being as small as possible while still providing all essential
features of a web browser, including HTML4, CSS, JavaScript, Cookies,
SSL, Non-blocking IO .

It is part of the KDE project, developed/maintained by the KDE team.

Simon Hausmann <simon@kde.org> .


Some notes about building, installing, running and technical stuff:

- if you want to compile with qt-embedded support, then you have to 
  
  * Configure this package with the --enable-qt-embedded configure
    switch!

  * compile qt/e without the two compiler flags -fshared-data and 
    -fshort-enums . You have to edit the qt compilation config file
    in $QTDIR/configs . (the reason is that otherwise jpeg support 
    doesn't work and loots of web sites use jpeg ;-)

    The other option is to compile *EVERYTHING* (including libjpeg, libmng,
    etc.) with those two compiler flags.

- configure with --enable-static --disable-shared and do a strip --strip-all
  to get a small binary

- if you have font problems under Qt/Embedded try removing the weird
  Babelfish font from fontsdir ;-)
  Oh, and make sure your Qt/Embedded (as of the 2.2.2 release) has the
  following patch applied:
  
  (from qfont_qws.cpp)
  int QFont::pixelSize() const
  {
    return d->req.pointSize/10;
  }

  I assume that this will not be necessary for >2.2.2 release of Qt/E .

- installing: make install will install things in the following way:

  * konqueror (startup shell script) and konq (real binary) will be
    install into $prefix

  * additional data (like html4.css or the charsets file) are being
    installed somewhere under $prefix/share

- If you want to use a HTTP proxy server for webbrowsing, make sure to
  set the HTTP_PROXY environment variable appropriately. Like for example
  HTTP_PROXY="http://proxy.foo.com:3128/"

  In addition the NO_PROXY_FOR environment variable is supported.
  Set it up to a list of servers for which you do not want to use
  a HTTP proxy server.

- The browser user agent value is set to 
  Mozilla/5.0 (compatible; Konqueror/2.0.9; Qt/E)
  by default. If you want to override this setting just set the
  HTTP_USER_AGENT environment variable to the appropriate value.

- Konqueror/Embedded (in particular the http ioslave) supports caching.
  It is disabled by default, however you can turn it on and control it
  by the following environment variables:

  KIO_HTTP_USECACHE (set to any value to turn on caching)
  KIO_HTTP_MAXCACHEAGE - Maximum age of cache in seconds (default 14 Days)
  KIO_HTTP_MAXCACHESIZE - Maximum cache size in Kilobytes (default 5Mb)

- More supported environment variables:

  KIO_HTTP_PROXY_CONNECT_TIMEOUT - default 10 seconds
  KIO_HTTP_CONNECT_TIMEOUT - default 20 seconds
  KIO_HTTP_RESPONSE_TIMEOUT - default 60 seconds

- Here's some info about how the kio slaves work and how the dcop
  communication between the http slave and the cookiejar is "emulated" .

  When a slave is to be started we create four pipes (see scheduler.cpp) ,
  two for kio-app<->slave communication and two for dcop-app<->slave
  communcation.

  Then we fork() .

  For each of the pipe pairs on both sides we create a KIO::Connection
  object. It provides all we need to have a simple command-plus-data
  pattern for communication.

  So we fork now, too :)

  +--
  | Slave side:
    
    One of the Connection objects is passed to the Slave implementation 
    (inherits SlaveBase)
   
    The other one is passed to a static connection variable in the
    DCOP client, used when the http slave does DCOPClient::call/send.

    Now we enter dispatchLoop() . Important: We do the select() only
    on the fds of the KIO connection, not on the dcop pipe fds.
    The reason is simple: dcop calls are never initiated from the app
    to the slave but always the other way around, so we don't need to
    select() on the dcop fd's aswell.

  +--
  | App side:

    Ah, I forgot to mention: On the slave side as well as on the app
    side, right after the fork(), we close the unused side of our
    pipes.

    One of the new connection objects is passed over the a new KIO::Slave
    object instance. KIO::Slave inherits from SlaveInterface, to which we
    indirectly pass over the connection obj and then connect a socket-
    notifier with a slot in KIO::Slave . That's fairly straightforward
    and quite almost the same way as in the real libkio in kdelibs :)

    Now we tell our single DCOP server object instance that there is a 
    new connection (to a new slave, which might issue dcop calls) .

  
