Merge branch 'experimental' into cookie_daemon
[uzbl-mobile] / README
1 ### THIS PROJECT IS NOT FOR:
2 * people want a browser that does everything
3 * people who want a browser with things like a built-in bookmark manager, address bar, forward/back buttons, ...
4 * people who expect something that works by default.  You'll need to read configs and write/edit scripts
5 * people who like nothing from this list: mpd, moc, wmii, dwm, awesome, mutt, pine, vim, dmenu, screen, irssi, weechat, bitlbee
6
7 ### TO NEW PEOPLE:
8 * please read the documentation in /usr/share/uzbl/docs
9 * invoke uzbl --help
10 * to get you started: `XDG_DATA_HOME=/usr/share/uzbl/examples/data XDG_CONFIG_HOME=/usr/share/uzbl/examples/config uzbl --uri www.archlinux.org`
11 * try and study the sample config, read the readme to find out how it works.
12 * You can change the url with commands (if you have setup the appropriate keybinds) but to be most effective it's better to do url editing/changing _outside_ of uzbl.
13   Eg, you can use the `load_from_*` dmenu based scripts to pick/edit a url or type a new one.
14 * If you have questions, you are likely to find answers in the FAQ or in the other documentation.
15
16
17 ### INTRODUCTION
18   Any program can only be really useful if it complies to the unix philosophy.
19   Web browsers are frequent violators of this principle:
20
21 * They build in way too much things into the browser, dramatically decreasing the options to do things the way you want.
22 * They store things in way too fancy formats (xml, rdf, sqlite, ... ) which are hard to store under version control, reuse in other scripts, ...
23
24 Time to change that!
25
26   Here are the general ideas (not all of these are implemented perfectly yet):
27
28 * each instance of uzbl renders 1 page (eg it's a small wrapper around webkit), no tabbing, tab previews, or speed dial things.
29   For "multiple instances management" use your window managers, scripts or wrappers.
30 * very simple, plaintext , changeable at runtime configuration
31 * various interfaces for (programmatic) interaction with uzbl (see below)
32 * customizable keyboard shortcuts in vim or emacs style (whatever user wants)
33 * "outsource" logic that is not browsing to external scripts under the users control:
34     - managing bookmarks
35     - loading a url from bookmarks, history,..  Editing the curent url
36     - control cookies
37     - handling of downloads, history logging, etc.
38     - management of cache.
39     - password management
40     - Leverage the power of utilities such as grep, awk, dmenu, zenity, wget, gnupg (password file) etc.
41 * listen to signals and do useful stuff when triggered.
42 * no ad blocking built in.
43   Alternatives:
44     - privoxy looks cool and perfectly demonstrates the unix philosphy.
45     - same for http://bfilter.sourceforge.net
46     - /etc/hosts (not very good cause you need root and it affects the whole system)
47       uzblctrl would need to support an option to list all images on a page, so you can easily pick the links to ads to add them to your /etc/hosts.
48 * vimperator/konqueror-like hyperlink following.
49 * password management. maybe an encrypted store that unlocks with an ssh key?
50 * no messing in the users $HOME or in /etc: no writing of anything unless the user (or sysadmin) asks for it.
51   We recommend using XDG basedir spec for separation of config, data and cache. and state should be a subdir in the config dir (not part of the spec yet) too.
52
53
54 ### CONFIGURATION / CONTROL:
55 The general idea is that uzbl by default is very bare bones.  you can send it commands to update settings and perform actions, through various interfaces.
56 There is a limited default configuration.  Please see config.h to see what it contains.
57 By default, there are *no* keybinds defined at all.  (Default keybinds would work counterproductive when you try to customize)
58 For examples of the possibilities what you can do, please see the sample config(s), and uzbl wiki page.
59 There are several interfaces to interact with uzbl:
60
61 * uzbl --config <filename>: <filename> will be read line by line, and the commands in it will be executed.  useful to configure uzbl at startup.
62   If you have a file in `$XDG_CONFIG_HOME/uzbl/config` (this expands to ~/.config/uzbl/config on most systems) it will be automatically recognized
63 * stdin: to write commands into stdin, use `--config -` (or `-c -`)
64 * interactive: you can enter commands (and bind them to shortcuts, even at runtime)
65   By default, the behaviour is modal (vi style):
66   command mode: every keystroke is interpreted to run commands
67   insert mode: keystrokes are not interpreted so you can enter text into html forms
68   But if you don't like modal interfaces, you can set `always_insert_mode` and configure a modkey to execute the commands. (emacs style).
69   There is also support for "chained" commands (multiple characters long) (with backspace/esc shortcuts), and keyworded commands.
70   Also you can have incremental matching on commands or match after pressing return.  (see sampleconfig for more info)
71   Also, copy paste works when typing commands:
72   * insert (paste X cliboard)
73   * shift insert (paste primary selection buffer)
74 * FIFO & socket file: if enabled by setting their paths through one of the above means, you can have socket and fifo files available which are very useful to programatically control uzbl (from scripts etc).
75   The advantage of the fifo is you can write plaintxt commands to it, but it's half duplex only (uzbl cannot send a response to you).
76   The socket is full duplex but you need a socket-compatible wrapper such as netcat to work with it, or uzblctrl of course,
77   an utitly we include with uzbl made especially for writing commnands to the socket (and at some point, it will be able to tell you the response
78   too):  `uzblctrl -s <socketfile> -c <command>`
79
80 When uzbl forks a new instance (eg "open in new window") it will use the same commandline arguments (eg the same --config <file>), except --uri and--name.
81 If you made changes to the configuration at runtime, these are not pased on to the child.
82
83 ### COMMAND SYNTAX
84 Uzbl will read commands via standard input, named fifo pipe (if `fifo_dir` is set) and IPC socket (when `socket_dir` is set).
85 For convenience, uzbl can also be instructed to read commands from a file on startup by using the `-c` option.  Indeed, the config file is nothing more than a list of commands.
86
87 Each command starts with the name of the command, which must be the first thing on a line; preceding whitespace is not allowed.
88 A command is terminated by a newline.  Empty lines and lines that start with the hash sign are ignored by the parser.  Command names are always written in lowercase.
89
90 The following commands are recognized:
91
92 * `set <key> = <value>`
93    - used for changing variables on the fly
94    - the changes are effective immediately; for example, setting the variable `uri` will make uzbl start loading, and changing `status_format` will make the status bar react immediately
95    - if you want to unset a string, use `set` with one space after the equals sign
96 * `print @<key>`
97    - use this to print the value of a variable.
98 * `bind <string> = <command>`
99    - sets the character sequence `<string>` to invoke `<command>` when typed interactively in uzbl
100    - there are a few tricks you can do:
101        * `<string>` ends with an underscore: the command will only be invoked after pressing return/enter. If the user enters text where `<string>` has the underscore, `%s` in the `<command>` string will be replaced by this text. (optional)
102        * `<string>` ends with an asterisk: similar behavior as with an underscore, but also makes the binding incremental (i.e. the command will be invoked on every keystroke).
103        * `<string>` ends on a different character: you need to type the full string, which will trigger the command immediately, without pressing enter/return.
104    - examples:
105        * `bind o _ = uri %s`
106          - uzbl will load the url when you type: 'o <url><enter>'
107        * `bind /*  = search %s`
108          - a search command which is called on every character typed after the slash, letting you see the search narrow down while typing.
109          - Hitting return, enter or esc will terminate the search.
110        * `bind ZZ  = exit`
111          - When you type `ZZ` and nothing else, the exit command will be triggered immediately.
112
113 * `back`
114 * `forward`
115 * `scroll_vert <amount>`
116 * `scroll_horz <amount>`
117    - amount is given in pixels(?) or as a percentage of the size of the view
118    - set amount to 100% to scroll a whole page
119 * `scroll_begin`
120 * `scroll_end`
121 * `reload`
122 * `reload_ign_cache`
123 * `stop`
124 * `zoom_in`
125 * `zoom_out`
126 * `uri <address>`
127 * `js <body>`
128    - execute the javascript in `<body>`
129    - remember that the commands must not contain line breaks
130 * `script <file>`
131    - execute the javascript in `<file>`
132 * `toggle_status`
133 * `spawn <executable> <additonal args>`
134    - runs a command; see EXTERNAL SCRIPTS for details
135    - PATH is searched so giving the full path to commands is not neccessary
136    - note that the arguments as specified in "EXTERNAL SCRIPTS" are appended at the end, so the argument numbers will be higher.
137 * `sh <command>`
138    - runs a shell command by expanding `%s` in the `shell_cmd` variable with the specified command; primarily useful as a shortcut for `spawn sh -c <body>`
139    - note that the arguments as specified in "EXTERNAL SCRIPTS" are appended at the end, so the argument numbers will be higher.
140 * `sync_spawn <executable> <additional args>`
141 * `sync_sh <command>`
142    - these are synchronous variants of `spawn` and `sh`, which means uzbl will wait for them to return
143    - you should only need to use these manually if you want to use a chain command in a handler that wants output from the command it runs
144 * `talk_to_socket <socketfile> <tokens/command>`
145    - lets uzbl talk to a socketfile
146 * `exit`
147 * `search <string>`
148 * `search_reverse <string>`
149    - search with no string will search for the next/previous occurrence of the string previously searched for
150 * `toggle_insert_mode <optional state>`
151    - if the optional state is 0, disable insert mode. If 1, enable insert mode.
152 * `dump_config`
153    - dumps your current config (which may have been changed at runtime) to stdout, in a format you can use to pipe into uzbl again (or use as config file)
154 * `keycmd <string>`
155 * `keycmd_nl <string>`
156    - keycmd sets the interactive command buffer to `<string>`.  If the given string is a valid binding, it will execute.  `Keycmd_nl` is like `keycmd`, but it also emulates a press of return, causing bindings with a parameter to execute.  For example, `keycmd_nl o google.com` would load the said url if you have a binding like `bind o _ = uri %s`.
157 * `keycmd_bs`
158    - erase (backspace) one character from the command buffer
159 * `chain <command> <command> ..`
160    - use for chaining multiple commands
161    - remember to quote the commands; one command must come as one parameter
162    - if you use `chain` with a handler script which must return some output (such as a cookie handler -- uzbl will wait for and use its output), use sync_spawn or sync_sh instead of spawn or sh in the command that should give the output
163 * `update_gui`
164    - update the contents of the status and title bars
165
166 ### VARIABLES AND CONSTANTS
167 Uzbl has a lot of internal variables and constants.  You can get the values (using the `print` command, see above), and for variables you can also change the value at
168 runtime.  Some of the values can be passed at start up through commandline arguments, others need to be set by using commands (eg in config file). 
169 Some of them have default values (see config.h)
170 Some variables have callback functions which will get called after setting the variable to perform some additional logic (see below)
171
172 Besides the builtin variables you can also define your own ones and use them in the exact same way as the buitin ones.
173
174 * Variables:
175   - uri (callback: load the uri)
176   - verbose: affects output on stdout
177   - mode:insert or command mode
178   - inject_html
179   - base_url: used when passing html through stdin
180   - html_endmarker: delimiter when passing html through stdin
181   - html_mode_timeout: consider end of html input after x seconds when no endmarker found
182   - keycmd: holds the input buffer (callback: update input buffer)
183   - status_message (callback: update title)
184   - show_status: show statusbar or not
185   - status_top: statusbar on top?
186   - status_format: marked up, to be expanded string for statusbar (callback: update statusbar)
187   - status_pbar_done: character to denote done % of pageload
188   - status_pbar_pending: character to denote pending % of pageload
189   - status_pbar_width: width of progressbar
190   - status_background: color which can be used to override Gtk theme.
191   - insert_indicator: string to denote insert mode
192   - command_indicator: string to denote command mode
193   - title_format_long: titlebar string when no statusbar shown (will be expanded
194   - title_format_short: titlebar string when statusbar shown (will be expanded)
195   - icon: path to icon for Gtk
196   - insert_mode: whether insert mode is active
197   - always_insert_mode: set this to true if you don't like modal (vim-like) interfaces
198   - reset_command_mode: automatically revert to command mode on pageload (unless always_insert_mode is set)
199   - modkey: modkey which can be pressed to activate keybind from inside insert mode
200   - load_finish_handler
201   - load_start_handler
202   - load_commit_handler
203   - history_handler
204   - download_handler
205   - cookie_handler
206   - new_window: handler to execute to invoke new uzbl window (TODO better name)
207   - fifo_dir: location to store fifo's
208   - socket_dir: location to store sockets
209   - http_debug: http debug mode (value 0-3)
210   - shell_cmd: alias which will be expanded to use shell commands (eg sh -c)
211   - proxy_url: http traffic socks proxy (eg: http://<host>:<port>)
212   - max_conns
213   - max_conns_host
214   - useragent: to be expanded strin
215   - zoom_level
216   - font_size
217   - monospace_size
218   - minimum_font_size
219   - disable_plugins (TODO rename to enable)
220   - disable_scripts (TODO rename to enable)
221   - autoload_images
222   - autoshrink_images: shrink images to window size (default 0)
223   - enable_spellcheck
224   - enable_private
225   - print_backgrounds: print background images? (default 0)
226   - stylesheet_uri: use this to override the pagelayout with a custom stylesheet
227   - resizable_text_areas
228   - default_encoding: iso-8859-1 by default
229   - enforce_96_dpi: 1 by default
230   - caret_browsing
231   - default_font_family = sans-serif
232   - monospace_font_family = monospace (example "Aerial Mono" )
233   - cursive_font_family = sans
234   - fantasy_font_family = "Pterra"
235   - serif_font_family = serif (example "DejaVu Serif")
236   - sans_serif_font_family = sans (example "DejaVu Sans")
237
238
239 * Constants (not dumpable or writeable):
240   - WEBKIT_MAJOR: set at compile time
241   - WEBKIT_MINOR: set at compile time
242   - WEBKIT_MICRO: set at compile time
243   - ARCH_UZBL: set at compile time
244   - COMMIT: set at compile time
245   - LOAD_PROGRESS
246   - LOAD_PROGRESSBAR
247   - TITLE
248   - SELECTED_URI
249   - MODE
250   - NAME: name of the uzbl instance (Xorg window id, unless set by cmdline arg) (TODO: can't we make this a variable?)
251
252
253 ### VARIABLE EXPANSION AND COMMAND/JAVA SCRIPT SUBSTITUTION
254
255 Variable expansion works pretty much as known from shell interpreters (sh, bash, etc.). This means you can
256 construct strings with uzbl variables in them and have uzbl replace the variable name with its contents.
257
258 In order to let uzbl know what to expand you'll need to prepend @ to the variable name:
259
260     print The variable \@show_status contains @show_status
261
262 The above example demonstrates two things:
263
264     * '\' is treated as escape character and will use the character immediatelly following it literallily
265       this means '\@show_status' will not expand to the variable content but be rather printed as
266       '@show_status'
267
268     * prepending the variable with '@' will expand to its contents
269
270     * like in the shell you can use @{uzbl_var} to denote the beginning/end of the variable name in
271       cases where it is not obvious what belongs to the name and what not.
272       E.g.:  print @{show_status}foobar
273
274
275 Command substitution will launch any commands and substitute the call with the return value of the command.
276
277 Uzbl will substitute any commands enclosed within @(  )@:
278
279     print Command substitution: @(uname -a)@
280
281 You can access any uzbl variable from within a command substitution:
282
283     print @(echo -n 'Accessing the show_status var from an external script, value: @show_status')@
284
285
286 Java script substitution works in the exact same way as command substitution but you will need to enclose
287 the java script in @< >@.
288
289     print The currently viewed document contains @<document.links.length>@ links
290
291 Variable expansion also works within a java script substitution.
292
293
294 When a piece of text needs to be XML escaped after it is expanded (for example,
295 in the status bar format), you can use @[ ]@ substitution:
296
297     print This text is XML escaped: @[<&>]@
298
299     # prints: This text is XML escaped: &lt;&amp;&gt;
300
301
302 NOTE: If you need to use literal @ or \ characters you will need to escape them:
303
304     print At sign: \@  and backslash: \\
305
306
307 ### TITLE AND STATUS BAR EVALUATION
308
309 The contents of the status bar can be customized by setting the status_format
310 variable. The contents of the window title can be customized by setting the
311 title_format_short variable (which is used when the status bar is displayed) and
312 the title_format_long variable (which is used when the status bar is not
313 displayed). Their values can be set using the expansion and substitution
314 techniques described above.
315
316 These variables are expanded in multiple stages; once when the variable is set,
317 and again every time that the status bar or window title are updated. Expansions
318 that should be evaluated on every update need to be escaped:
319
320     set title_format_short = @(date)@
321     # this expansion will be evaluated when the variable is set.
322     # the title will stay constant with the date that the variable was set.
323
324     set title_format_short = \@(date)\@
325     # this expansion will be evaluated when the window title is updated.
326     # the date in the title will change when you change pages, for example.
327
328     set title_format_short = \\\@(date)\\\@
329     # the title will stay constant as a literal "@(date)@"
330
331 The status_format variable can contain Pango markup (see
332 <http://library.gnome.org/devel/pango/stable/PangoMarkupFormat.html>). In the
333 status_format, variables that might contain characters like '<', '&' and '>',
334 should be wrapped in a @[]@ substitution so that they don't interfere with the
335 status bar's markup; see the example config for examples.
336
337
338 ### EXTERNAL SCRIPTS
339 You can use external scripts with uzbl the following ways:
340
341 * let uzbl call them. these scripts are called handlers in the uzbl config. used for handling logging history, handling a new download,..
342 * call them yourself from inside uzbl.  you can bind keys for this. examples: add new bookmark, load new url,..
343 * You could also use xbindkeys or your WM config to trigger scripts if uzbl does not have focus
344
345 Have a look at the sample configs and scripts!
346
347 Handler scripts that are called by uzbl are passed the following arguments:
348
349     $1 uzbl-config-file
350     $2 uzbl-pid
351     $3 uzbl-x-window-id
352     $4 uzbl_fifo-filename
353     $5 uzbl_socket-filename
354     $6 current page url
355     $7 current page title
356     .. [ script specific ] (optional)
357
358 The script specific arguments are this:
359
360 * history:
361
362     $8 date of visit (Y-m-d H:i:s localtime)
363
364 * add bookmark:
365
366     none
367
368 * download:
369
370     $8 url of item to download
371
372 * cookie handler
373
374     $8 GET/PUT
375     $9 request address scheme (e.g. http or https)
376     $10 request address host (if current page url is www.foo.com/somepage, this could be something else than foo, eg advertising from another host)
377     $11 request address path
378     $12 cookie (only with PUT requests)
379
380
381 Custom, userdefined scripts (`spawn foo bar`) get first the arguments as specified in the config and then the above 7 are added at the end.
382
383 ### JAVASCRIPT HELPER OBJECT
384
385 Javascript code run from uzbl is given a special object in the global namespace which gives special privileges to these scripts. This object is called `Uzbl`, and it is added and removed before and after the script execution so that it is hidden to web javascripts (There is no race condition, since all the javascript code runs in a single thread)
386
387 Currently, the `Uzbl` object provides only one function:
388
389 * `Uzbl.run( <command> )`
390    - command is any uzbl command as defined above
391    - return value: a string, either empty or containing the output of the command. Very few commands return their output currently, including js, script, and print.
392    - Examples:
393        * `Uzbl.run("spawn insert_bookmark.sh")`
394        * `uri = Uzbl.run("print @uri")` (see variable expansion below)
395
396 ### JAVASCRIPT SECURITY
397
398 Since defined variables and functions are set in the global namespace (`window` object) as default, it is recommended to wrap your scripts like this:
399
400     (function(Uzbl) {
401         ...
402     })(Uzbl);
403
404 This way, everything is kept private. It also turns Uzbl into a local variable, which can be accessed from callback functions defined inside. However for some situations, isolating everything isn't an option, for example, with binds. You can define them directly in the script body, and use `var Uzbl = window.Uzbl;` to make the Uzbl variable local, as in the following example:
405
406     function f() {
407         var Uzbl = window.Uzbl;
408         Uzbl.run(...);
409         setTimeout(function() {
410             Uzbl.run(...);
411         }, 500);
412     }
413
414 Copying the Uzbl object and creating public functions should be taken with care to avoid creating security holes. Keep in mind that the "f" function above would be defined in the `window` object, and as such any javascript in the current page can call it.
415
416 ### COMMAND LINE ARGUMENTS
417     uzbl [ uri ]
418     -u, --uri=URI            Uri to load at startup (equivalent to 'uzbl <uri>' or 'set uri = URI' after uzbl has launched)
419     -v, --verbose            Whether to print all messages or just errors.
420     -n, --name=NAME          Name of the current instance (defaults to Xorg window id)
421     -c, --config=FILE        Path to config file or '-' for stdin
422     -s, --socket=SOCKET      Socket ID
423     -g, --geometry=GEOMETRY  Set window geometry (format: WIDTHxHEIGHT+-X+-Y)
424     -V, --version            Print the version and exit
425     --display=DISPLAY        X display to use
426     --help                   Help
427
428
429
430
431 ### BUGS
432 Please report new issues @ uzbl.org/bugs