# HG changeset patch
# User meillo@marmaro.de
# Date 1270283613 -7200
# Node ID 9282c4cea18c5f37bdc7c079cadc2a0bf6daab1b
# Parent  4f2b2defbc8cf20ac50ec1a71deb9cde8e9aa865
more about uzbl design

diff -r 4f2b2defbc8c -r 9282c4cea18c unix-phil.ms
--- a/unix-phil.ms	Tue Mar 30 23:20:40 2010 +0200
+++ b/unix-phil.ms	Sat Apr 03 10:33:33 2010 +0200
@@ -1301,13 +1301,45 @@
 .B "Avoid captive user interfaces" .
 One could say, that uzbl, to a large extend, actually \fIis\fP
 a captive user interface.
-But the difference to most 
-
+But the difference to most other web browsers is, that uzbl is only
+the captive user interface frontend and the core of the backend.
+Many parts of the backend are independed of uzbl.
+Some are distributed with uzbl, for some external programs, handler scripts
+are distributed, arbitrary additional functionality can be added if desired.
+.PP
+The frontend is captive \(en that is true.
+This is okay for the task of browsing the web, as this task is only relevant
+for humans.
+Automated programs would \fIcrawl\fP the web.
+That means, they read the source directly.
+The source includes all the semantics.
+The graphical representation is just for humans to transfer the semantics
+more intuitively.
 
 .PP
 .B "Make every program a filter" .
-.B "Small is beautiful
-and
+Graphical web browsers are almost dead ends in the chain of information flow.
+Thus it is difficult to see what graphical web browsers should filter.
+Graphical web browsers exist almost only for interactive use by humans.
+The only case when one might want to automate the rendering function is
+to generate images of rendered webpages.
+
+.PP
+.B "Small is beautiful"
+is not easy to apply to a web browser, primary because the rendering task
+is very complex.
+Modern web browsers will always consist of many thousand lines of code,
+unfortunately.
+Using the toolchest approach and wrappers can split the browser into
+several small parts, tough.
+.PP
+Uzbl-core consists of about 3\,500 lines of C code.
+The distribution includes another 3\,500 lines of Shell and Python code,
+which are the handler scripts and plugins like a modal interface.
+Further more, uzbl uses external tools like \fIwget\fP, \fInetcat\fP.
+Up to this point, uzbl looks pretty neat and small.
+The ugly part of uzbl is the web content renderer webkit.
+Webkit consists of roughly 400\,000 (!) lines of code.
 
 .PP
 .B "Build a prototype as soon as possible" .
@@ -1333,6 +1365,24 @@
 .LP
 broken web
 
+.PP
+But all functionality should be accessable at the backend too.
+Uzbl fails here, mainly because of webkit.
+Uzbl is not clearly separated into frontend and backend,
+especially the render engine is not an separate building part,
+like, for instance, the download manager is.
+This comes from the design of webkit.
+Webkit is not a self-standing program but a library to include.
+This might be of need for a graphical application to avoid complexity,
+but webkit has a lot of features included that do not belong to the
+webpage rendering job; a browsing history is just one example.
+.PP
+Ideally, webkit would just render the source of a webpage into a
+nice formated representation.
+.PP
+be a black box
+
+
 
 .NH 2
 Summary uzbl