1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
FAQ
---
### I just installed uzbl but it doesn't do much. What now?
Uzbl includes very limited default settings (statusbar settings, but no keybinds, history/download handlers etc.)
Look at /usr/share/uzbl/docs/config.h to see the default settings.
Have a look in /usr/share/uzbl/examples/configs to see what you can do.
If you save a config as $XDG\_CONFIG\_HOME/uzbl/config it will be loaded automatically.
Running with the `--verbose` flag on a command line can also be interesting.
To get you started, try this:
`XDG_DATA_HOME=/usr/share/uzbl/examples/data XDG_CONFIG_HOME=/usr/share/uzbl/examples/config uzbl`
It will temporarily override your $XDG\_CONFIG\_HOME and $XDG\_DATA\_HOME
variables so you can try the sample stuff directly in /usr/share/uzbl/examples.
If you like what you can do, you can copy the sample stuff into your ~ and edit to your liking.
### Why don't you just use a reasonable config by default?
We actually did some attempts to make uzbl "usable by default" but in the
end we had to conclude it cannot be done because of the following reasons:
* We don't want to store anything "automagically" in the users home.
Some people prefer different file/directory layouts, most of just want to
control the files in $HOME themselves.
* We considered the option of having a global '/etc/uzbl' which user
specific ones could override but that would overcomplicate things.
* We adhere to the [FHS](http://www.pathname.com/fhs/) (`man hier`), so
`uzbl -c /usr/share/...` is not an option.
So even though we would like to make uzbl more usable by default, we think
there is no sensible way to do it. Maybe downstream packagers could provide
a note that users could copy the examples from /usr/share/uzbl/examples into
their homes, because really, that's all that is needed if you want it to
just "work" without controlling how yourself. (unless you have no
xdg variables set, in which case you should be smart enough to edit the sample
config yourself).
### Where is the location bar? How do I change the URL ?
Uzbl has no location bar. All changes to the uri (editing of current uri, typing new uri, loading of uri from bookmarks/history/...) happens *outside* of uzbl.
Have a look at the sample scripts in /usr/share/uzbl/examples. Most of our examples use dmenu which is a nifty little tool to pick an item from a list of items (very
useful with history/bookmarks) with a limited set of keystrokes. see man dmenu.
You can also use it to make edits to a uri (press tab to load it into the
search field) or type a url from scratch, though dmenu
is not the most suitable editor. We're looking into a better way to make edits.
Tools such as Zenity are also quite suited for this.
And you can always make keybinds to load the current uri in the command field, paste/load urls from
clipboard etc.
### Where are the widgets (forward, back,.. button etc)
Uzbl's layout only contains what you really need to see. we only have a statusbar, which even can also be disabled. There are no buttons, but we do
have lots of keybinding possibilities.
### No tabs? Why do you need a new window for each page?
We stick to "one page per uzbl instance" because that's a simple, clean and flexible method. We believe "multiple instances management" is something that must
be handled outside of uzbl by a separate/different program. Here are some solutions:
* Many window managers can (and should) handle this by default. Xmonads tabbed layout, Wmii's stacked layout, fluxbox or kwin tabs and so on.
* Uzbl supports acting as a GtkPlug to plug into GtkSockets (Xembed) so you can embed uzbl instances in other Gtk applications.
This allows several implementatinos, a popular one is [uzbl_tabbed.py](http://www.uzbl.org/wiki/uzbl_tabbed)
* If you want highest customizablity, you need the 3rd option:
You can also write a custom script. The only thing you need to do is focus/maximize the instance you want,
keep the others out of sight and use tools like dmenu and wmctrl to switch instances.
This allows you to use application-specific properties (such as uzbl tag, name etc).
For more information about this approach, see docs/multiple-instances-management.
(If you want to work on such script, let us know and we might include it along with the other sample scripts)
### What? No support for bookmarks/history/downloads/cookies/... ? Your project sucks!
We do not support *management* of those things, because we believe a browser should only do browsing. We are firm believers in the unix philosophy.
You have to look at the bigger picture. In fact, we do support all these things. Take bookmarks as an example:
* we support keybinding and spawning external programs, so you can bind a key to spawn any script you want
* Your script receives properties such as the current url, window title etc.
* You can then call a tool such as zenity to prompt for any more information you may want to specify (tags,...)
* You have the freedom to store the bookmarks in whichever format you want. (plaintext, sqlite, any database, on a remote system, in version control, ...)
* To load a bookmark, you trigger another script which invokes a tool such as dmenu to let you pick a bookmark. Your script can send the command to load the url to uzbl very easily by using the socket or fifo interface.
* To manage your bookmarks, you can use whatever you want, depending on how you store them (simple text editor, database interface, ... )
These ideas are something we want to consistently apply throughout the entire application. (Even more, throughout our entire desktop environment)
In fact, we actually ship various sample scripts and some sample configs that make it easy for you to implement your workflow.
### Okay, what can I actually do? What commands are there? How do I get more information?
* Commands and other features are documented in README. Read it.
* You should also peek into the sampleconfigs to see how commands are used in practice.
### Why can't I type anything in forms? How does the keybinding work?
You are in command mode, not in insert mode.
* command mode: you can trigger actions inside uzbl with minimum amount of keypresses (eg 'b' to go back, 'ZZ' to quit etc) (see config examples), but not to type actual text into forms, because all your keypresses are interpreted.
* insert mode: after going into insert mode (by default this is the 'i' binding from inside command mode), your keypresses are not interpreted but passed on, so you can enter text into forms. Press Esc to go out of insert mode.
The above method is called "modal" as inspired on VI. If you don't like
this you can easily change this:
* enable always\_insert\_mode in your config. You will always be in insert mode.
* configure a modkey. Since your keypresses are not interpreted anymore to trigger actions, you need a modkey to do things (eg alt+'b' to go back instead of just 'b' from command mode)
This method is how many applications work.
Both have their pro's and cons. We don't want to force anyone in using
either, so by tuning the modkey and always\_insert\_mode settings you can pick
whichever method you like, or both at the same time (command mode, insert mode, and the modkey to perform actions while in insert mode)
### Why do you depend on gtk?
Uzbl itself doesn't use much gtk stuff (only the statusbar) so we could do without gtk. But Webkit needs a widget toolkit to create widgets (think javascript popups, html forms etc).
Officially, it also supports QT and wxwigdets. There are also some unofficial patchsets floating on the interwebs for the EFL and FLTK toolkits. One could argue we don't need no popups or fancy form widgets and you could have a point, but
we prefer being reasonably assured that things work as they are supposed to rather then using some obscure patchset which may be incomplete, broken and/or badly designed, or wasting time ourselves in what is not our core objective.
Note that we do *not* depend on any Gnome libraries such as gconf. _That_ would be something worth complaining about :)
### Do you support flash? javascript? Ajax? Recent html/css/.. standards?
Yes, Webkit takes care of all of that. Not that we like all of these, but you can use them if you want.
### What's the difference between the socket file and the fifo?
They both have advantages and disadvantages:
* fifo's are _very_ easy to work with. You can write just plaintext commands into them, but they are unidirectional (you can only communicate in one direction)
* Sockets are bidirectional but more complex. You cannot just write a plaintext string into them. In shellscripts you can use socat to work with sockets, when programming you need to use library functions.
So, when writing scripts, using fifo's is usually the fastest method (because you do not need to fork another process), so fifo is preferred unless you need a response.
### What the hell is this 'XDG' stuff??
You'll notice our example scripts and configs use variables such as `$XDG_CONFIG_HOME` and `$XDG_DATA_HOME`.
Most of us really like the [xdg basedir spec](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html)
so our example material folows it. Basically it helps you keeping a clean `$HOME` and it separates config, data and cache.
If these variables are not defined on your system, it could be that you need to install an xdg package.
If you don't like this, no one is stopping you from changing the scripts and configs to point to a single `$HOME/.uzbl` directory or whatever you want.
### Does the world really need another browser?
We did try a lot of browsers, and we do not suffer [NIH](http://en.wikipedia.org/wiki/Not_Invented_Here).
We believe that the approach taken by way too many browsers is wrong. We do not want browsers that try to do everything,
instead we prefer a system where different applications work together, which gives plenty of advantages.
We also like open source. We take a lot of things from other projects and we also try to contribute to other projects.
### What? You call all of this user-friendly?
Yes. If you don't agree, don't use it :)
|
