comparison unix-phil.ms @ 37:9282c4cea18c

more about uzbl design
author meillo@marmaro.de
date Sat, 03 Apr 2010 10:33:33 +0200
parents 4f2b2defbc8c
children 3628e9649046
comparison
equal deleted inserted replaced
36:4f2b2defbc8c 37:9282c4cea18c
1299 1299
1300 .PP 1300 .PP
1301 .B "Avoid captive user interfaces" . 1301 .B "Avoid captive user interfaces" .
1302 One could say, that uzbl, to a large extend, actually \fIis\fP 1302 One could say, that uzbl, to a large extend, actually \fIis\fP
1303 a captive user interface. 1303 a captive user interface.
1304 But the difference to most 1304 But the difference to most other web browsers is, that uzbl is only
1305 1305 the captive user interface frontend and the core of the backend.
1306 Many parts of the backend are independed of uzbl.
1307 Some are distributed with uzbl, for some external programs, handler scripts
1308 are distributed, arbitrary additional functionality can be added if desired.
1309 .PP
1310 The frontend is captive \(en that is true.
1311 This is okay for the task of browsing the web, as this task is only relevant
1312 for humans.
1313 Automated programs would \fIcrawl\fP the web.
1314 That means, they read the source directly.
1315 The source includes all the semantics.
1316 The graphical representation is just for humans to transfer the semantics
1317 more intuitively.
1306 1318
1307 .PP 1319 .PP
1308 .B "Make every program a filter" . 1320 .B "Make every program a filter" .
1309 .B "Small is beautiful 1321 Graphical web browsers are almost dead ends in the chain of information flow.
1310 and 1322 Thus it is difficult to see what graphical web browsers should filter.
1323 Graphical web browsers exist almost only for interactive use by humans.
1324 The only case when one might want to automate the rendering function is
1325 to generate images of rendered webpages.
1326
1327 .PP
1328 .B "Small is beautiful"
1329 is not easy to apply to a web browser, primary because the rendering task
1330 is very complex.
1331 Modern web browsers will always consist of many thousand lines of code,
1332 unfortunately.
1333 Using the toolchest approach and wrappers can split the browser into
1334 several small parts, tough.
1335 .PP
1336 Uzbl-core consists of about 3\,500 lines of C code.
1337 The distribution includes another 3\,500 lines of Shell and Python code,
1338 which are the handler scripts and plugins like a modal interface.
1339 Further more, uzbl uses external tools like \fIwget\fP, \fInetcat\fP.
1340 Up to this point, uzbl looks pretty neat and small.
1341 The ugly part of uzbl is the web content renderer webkit.
1342 Webkit consists of roughly 400\,000 (!) lines of code.
1311 1343
1312 .PP 1344 .PP
1313 .B "Build a prototype as soon as possible" . 1345 .B "Build a prototype as soon as possible" .
1314 Plaetinck made his code public, right from the beginning. 1346 Plaetinck made his code public, right from the beginning.
1315 Discussion and development was open to everyone interessted. 1347 Discussion and development was open to everyone interessted.
1331 .NH 2 1363 .NH 2
1332 Problems 1364 Problems
1333 .LP 1365 .LP
1334 broken web 1366 broken web
1335 1367
1368 .PP
1369 But all functionality should be accessable at the backend too.
1370 Uzbl fails here, mainly because of webkit.
1371 Uzbl is not clearly separated into frontend and backend,
1372 especially the render engine is not an separate building part,
1373 like, for instance, the download manager is.
1374 This comes from the design of webkit.
1375 Webkit is not a self-standing program but a library to include.
1376 This might be of need for a graphical application to avoid complexity,
1377 but webkit has a lot of features included that do not belong to the
1378 webpage rendering job; a browsing history is just one example.
1379 .PP
1380 Ideally, webkit would just render the source of a webpage into a
1381 nice formated representation.
1382 .PP
1383 be a black box
1384
1385
1336 1386
1337 .NH 2 1387 .NH 2
1338 Summary uzbl 1388 Summary uzbl
1339 .LP 1389 .LP
1340 1390