docs/unix-phil: unix-phil.ms comparison

comparison unix-phil.ms @ 36:4f2b2defbc8c

some rework and more about uzbl design (ch05)

author	meillo@marmaro.de
date	Tue, 30 Mar 2010 23:20:40 +0200
parents	f11406a85319
children	9282c4cea18c

comparison

equal deleted inserted replaced

-:f11406a85319
+:4f2b2defbc8c
 .\".if n .pl 1000i
-.\".nr PS 11
+.nr PS 11
-.\".nr VS 13
+.nr VS 13
 .de XX
 .pl 1v
 ..
 .em XX
 .\".nr PI 0
 as identified by Gancarz.
 .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
+The common definition of a web browser is, of course, highly influenced by
-existing implementations of web browsers which are degenerated.
+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.
 How could they perform this job better, than programs that exist only for
 this very job?
 And how could anyone want less than the best download manager available?
 .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,
+Rendering the \s-1HTML\s0 sources is a different job, too.
-which is covered by the webkit render engine, in uzbl's case.
+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
+are also not the job of a web browser.
-ones that exist to handle such data.
+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.''
 .R
 .PP
 The lesser tenet
 .B "allow the user to tailor the environment
 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
+.B "Use software leverage to your advantage" .
-and
+Shell scripts are a good choice to extend uzbl.
-.B "Use shell scripts to increase leverage and portability" .
+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" .
 .B "Small is beautiful
 and
 Actually, all development was community driven.
 Plaetinck says:
 ``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/
 .]
 .NH 2

Mercurial > docs > unix-phil

comparison unix-phil.ms @ 36:4f2b2defbc8c