### THIS PROJECT IS NOT FOR: * people want a browser that does everything * people who want a browser with things like a built-in bookmark manager, address bar, forward/back buttons, ... * people who expect something that works by default. You'll need to read configs and write/edit scripts * people who like nothing from this list: mpd, moc, wmii, dwm, awesome, xmonad, mutt, pine, vim, dmenu, screen, irssi, weechat, bitlbee ### TO NEW PEOPLE: * invoke uzbl-browser --help * to get you started: `XDG_DATA_HOME=/usr/share/uzbl/examples/data XDG_CONFIG_HOME=/usr/share/uzbl/examples/config uzbl-browser --uri www.archlinux.org` * alternatively, copy the above data to your real `$XDG_DATA_HOME` and `$XDG_CONFIG_HOME` directories * try and study the sample config, read the readme to find out how it works. * 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-browser. Eg, you can use the `load_from_*` dmenu based scripts to pick/edit a url or type a new one. * If you have questions, you are likely to find answers in the FAQ or in the other documentation. * documentation is in /usr/share/uzbl/docs ### INTRODUCTION Any program can only be really useful if it complies to the unix philosophy. Web browsers are frequent violators of this principle: * They build in way too much things into the browser, dramatically decreasing the options to do things the way you want. * They store things in way too fancy formats (xml, rdf, sqlite, ... ) which are hard to store under version control, reuse in other scripts, ... Time to change that! Here are the general ideas (not all of these are implemented perfectly yet): * each instance of uzbl renders 1 page (eg it's a small wrapper around webkit), no tabbing, tab previews, or speed dial things. For "multiple instances management" use your window managers, scripts or wrappers. * very simple, plaintext , changeable at runtime configuration * various interfaces for (programmatic) interaction with uzbl (see below) * customizable keyboard shortcuts in vim or emacs style (whatever user wants) * "outsource" logic that is not browsing to external scripts under the users control: - managing bookmarks - loading a url from bookmarks, history,.. Editing the curent url - control cookies - handling of downloads, history logging, etc. - management of cache. - password management - Leverage the power of utilities such as grep, awk, dmenu, zenity, wget, gnupg (password file) etc. * listen to signals and do useful stuff when triggered. * no ad blocking built in. Alternatives: - privoxy looks cool and perfectly demonstrates the unix philosphy. - same for http://bfilter.sourceforge.net - /etc/hosts (not very good cause you need root and it affects the whole system) one can list all images on a page using the socket, so you can easily pick the links to ads to add them to your /etc/hosts. * vimperator/konqueror-like hyperlink following. * password management. maybe an encrypted store that unlocks with an ssh key? * no messing in the users $HOME or in /etc: no writing of anything unless the user (or sysadmin) asks for it. 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. ### CONFIGURATION / CONTROL: 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. There is a limited default configuration. Please see config.h to see what it contains. By default, there are *no* keybinds defined at all. (Default keybinds would work counterproductive when you try to customize) For examples of the possibilities what you can do, please see the sample config(s), and uzbl wiki page. There are several interfaces to interact with uzbl: * uzbl --config : will be read line by line, and the commands in it will be executed. useful to configure uzbl at startup. 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 * stdin: to write commands into stdin, use `--config -` (or `-c -`) * interactive: you can enter commands (and bind them to shortcuts, even at runtime) By default, the behaviour is modal (vi style): command mode: every keystroke is interpreted to run commands insert mode: keystrokes are not interpreted so you can enter text into html forms But if you don't like modal interfaces, you can set `always_insert_mode` and configure a modkey to execute the commands. (emacs style). There is also support for "chained" commands (multiple characters long) (with backspace/esc shortcuts), and keyworded commands. Also you can have incremental matching on commands or match after pressing return. (see sampleconfig for more info) Also, copy paste works when typing commands: * insert (paste X cliboard) * shift insert (paste primary selection buffer) * 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). 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). The socket is full duplex but you need a socket-compatible wrapper such as socat to work with it. For example: echo | socat - unix-connect: When uzbl forks a new instance (eg "open in new window") it will use the same commandline arguments (eg the same --config ), except --uri and--name. If you made changes to the configuration at runtime, these are not pased on to the child. ### COMMAND SYNTAX Uzbl-browser will read commands via standard input, named fifo pipe (if `fifo_dir` is set) and IPC socket (when `socket_dir` is set). 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. Each command starts with the name of the command or an uzbl variable that expands to it. 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. The following commands are recognized: * `set = ` - used for changing variables on the fly - 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 - if you want to unset a string, use `set` with one space after the equals sign * `print @` - use this to print the value of a variable. * `bind = ` - sets the character sequence `` to invoke `` when typed interactively in uzbl - there are a few tricks you can do: * `` ends with an underscore: the command will only be invoked after pressing return/enter. If the user enters text where `` has the underscore, `%s` in the `` string will be replaced by this text. (optional) * `` 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). * `` ends on a different character: you need to type the full string, which will trigger the command immediately, without pressing enter/return. - examples: * `bind o _ = uri %s` - uzbl will load the url when you type: 'o ' * `bind /* = search %s` - a search command which is called on every character typed after the slash, letting you see the search narrow down while typing. - Hitting return, enter or esc will terminate the search. * `bind ZZ = exit` - When you type `ZZ` and nothing else, the exit command will be triggered immediately. * `back` * `forward` * `scroll_vert ` * `scroll_horz ` - amount is given in pixels(?) or as a percentage of the size of the view - set amount to 100% to scroll a whole page * `scroll_begin` * `scroll_end` * `reload` * `reload_ign_cache` * `stop` * `zoom_in` * `zoom_out` * `uri
` * `js ` - execute the javascript in `` - remember that the commands must not contain line breaks * `script ` - execute the javascript in `` * `toggle_status` * `spawn ` - runs a command; see EXTERNAL SCRIPTS for details - PATH is searched so giving the full path to commands is not neccessary - note that the arguments as specified in "EXTERNAL SCRIPTS" are appended at the end, so the argument numbers will be higher. * `sh ` - 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 ` - note that the arguments as specified in "EXTERNAL SCRIPTS" are appended at the end, so the argument numbers will be higher. * `sync_spawn ` * `sync_sh ` - these are synchronous variants of `spawn` and `sh`, which means uzbl will wait for them to return - 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 * `talk_to_socket ` - lets uzbl talk to a socketfile * `exit` * `search ` * `search_reverse ` - search with no string will search for the next/previous occurrence of the string previously searched for * `toggle_insert_mode ` TODO new plugin based syntax - if the optional state is 0, disable insert mode. If 1, enable insert mode. * `dump_config` - 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) * `keycmd ` * `keycmd_nl ` - keycmd sets the interactive command buffer to ``. 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`. * `keycmd_bs` - erase (backspace) one character from the command buffer * `chain ..` - use for chaining multiple commands - remember to quote the commands; one command must come as one parameter - 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 * `update_gui` - update the contents of the status and title bars * `event [event_details]` - send custom event * menu_add