# HG changeset patch # User meillo@marmaro.de # Date 1269984040 -7200 # Node ID 4f2b2defbc8cf20ac50ec1a71deb9cde8e9aa865 # Parent f11406a85319390e288a680b899000b0be1ca4c0 some rework and more about uzbl design (ch05) diff -r f11406a85319 -r 4f2b2defbc8c unix-phil.ms --- a/unix-phil.ms Sat Mar 27 14:27:36 2010 +0100 +++ b/unix-phil.ms Tue Mar 30 23:20:40 2010 +0200 @@ -1,6 +1,6 @@ .\".if n .pl 1000i -.\".nr PS 11 -.\".nr VS 13 +.nr PS 11 +.nr VS 13 .de XX .pl 1v .. @@ -1205,11 +1205,12 @@ .PP .B "Make each program do one thing well" . Uzbl tries to be a web browser and nothing else. -The common definition of a web browser is of course highly influenced by -existing implementations of web browsers which are degenerated. +The common definition of a web browser is, of course, highly influenced by +existing implementations of web browsers, although they are degenerated. Web browsers should be programs to browse the web, and nothing more. This is the one thing they should do, as demanded by the Unix Philosophy. -Web browsers should not manage downloads. +.PP +Web browsers should, for instance, not manage downloads. This is the job download managers exist for. Download managers do primary care about being good in downloading files. Modern web browsers provide download management only as a secondary feature. @@ -1219,12 +1220,15 @@ .PP A web browser's job is to let the user browse the web. This means, navigating through websites by following links. -Rendering the \s-1HTML\s0 sources is a different job, -which is covered by the webkit render engine, in uzbl's case. +Rendering the \s-1HTML\s0 sources is a different job, too. +It is covered by the webkit render engine, in uzbl's case. Audio and video content and files like PostScript, \s-1PDF\s0, and the like, -should be handled by external applications \(en -ones that exist to handle such data. +are also not the job of a web browser. +They should be handled by external applications \(en +ones which's job is to handle such data. Uzbl strives to do it this way. +.PP +Remember Doug McIlroy: .I ``Write programs that do one thing and do it well. Write programs to work together.'' @@ -1235,31 +1239,70 @@ matches good here. There was the question, how anyone could want anything less than the best program for the job. -But as personal preferences matter much, it is also important to ask: +But as personal preferences matter much, +it is probably more important to ask: How could anyone want something else than his preferred program for the job? +.PP Usually users want one program for one job. Hence, whenever the task is, for instance, downloading, -the same download manager should be used. +exactly one download manager should be used. More advanced users might want to have this download manager in this situation and that one in that situation. They should be able to configure it this way. With uzbl, one can use any download manager the user wants. -To switch to a different one, only one line in the small handler script +To switch to a different one, only one line in a small handler script needs to be changed. -Alternatively it would be possible to query an environment variable +Alternatively it would be possible to query an entry in a global file +or an environment variable, which specifies the download manager to use, in the handler script. +.PP As uzbl does neither have its own download manager nor depends on a specific one, thus uzbl's browsing abilities will not be lowered by having a bad download manager. +Uzbl's download capabilities will just as good as the ones of the best +download manager available on the system. Of course, this applies to all of the other supplimentary tools, too. .PP -.B "Use software leverage to your advantage -and -.B "Use shell scripts to increase leverage and portability" . +.B "Use software leverage to your advantage" . +Shell scripts are a good choice to extend uzbl. +Uzbl is designed to be extended by external tools. +These external tools are usually wrapped by small handler shell scripts. +Shell scripts are the glue in this approach. +They make the various parts fit together. +.PP +As an example, the history mechanism of uzbl shall be presented. +Uzbl is configured to spawn a script to append an entry to the history +whenever the event of a fully loaded page occurs. +The script to append the entry to the history not much more than: +.DS +.CW +#!/bin/sh +file=/path/to/uzbl-history +echo `date +'%Y-%m-%d %H:%M:%S'`" $6 $7" >> $file +.DE +\f(CW$6\fP and \f(CW$7\fP expand to the \s-1URL\s0 and the page title. +For loading an entry, a key is bound to spawn a load from history script. +The script reverses the history to have newer entries first, +then displays \fIdmenu\fP to select an item, +and afterwards writes the selected \s-1URL\s0 into uzbl's command input pipe. +With error checking and corner cases removed, the script looks like this: +.DS +.CW +#!/bin/sh +file=/path/to/uzbl-history +goto=`tac $file | dmenu | cut -d' ' -f 3` +echo "uri $goto" > $4 +.DE +\f(CW$4\fP expands to the path of the command input pipe of the current +uzbl instance. .PP .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 + .PP .B "Make every program a filter" . @@ -1280,7 +1323,7 @@ ``Right now I hardly code anything myself for Uzbl. I just merge in other people's code, ponder a lot, and lead the discussions.'' .[ -FIXME +%A FIXME %O http://lwn.net/Articles/341245/ .]