Meet Uzbl — a Web Browser With the Unix Philosophy

DigDuality writes "Dieter@be over at Arch Linux forums, a release engineer for Arch Linux, got inspired by this post. The idea? To create a browser based on the Unix philosophy: 'Write programs that do one thing and do it well, programs that work well together, programs to handle text streams because that is a universal interface,' among other points. The result? A fast, low-resource browser named Uzbl, based on WebKit, which passes the Acid3 Test with a perfect score. The browser is controlled (by default) by vim-like keybindings, not too dissimilar to vimperator for Firefox. Things like URL changing, loading/saving of bookmarks, saving history, and downloads are handled through external scripts that you write (though the Uzbl software does come with some nice scripts for you to use). It fits great in a tiling window manager and plays extremely well with dmenu. The learning curve is a bit steep, but once you get used to it, it's smooth sailing. Not bad for alpha software. Though built for Arch, it has been reported to work on Ubuntu."

Comments

Really fun browser

[Minozake]

This is a really fun web browser to tinker with. However, I'd recommend people should use a backup browser until they get it up and functioning to their specific needs. I'm still trying to work around with the cookies scripts, myself.

Re:Really fun browser

[Bigjeff5]

You missed the part about the Unix philosophy, which is "Do one thing, and do it well". It browses the web, apparently very very well. But storing cookies for later use isn't really browsing, now, is it? Neither are favorites or bookmarks or history and all that. If you want that stuff, you have to write scripts for it.

Neat idea, I'd never use it though. Too lazy.

Re:Really fun browser

[Kjella]

You missed the part about the Unix philosophy, which is "Do one thing, and do it well". It browses the web, apparently very very well. But storing cookies for later use isn't really browsing, now, is it? Neither are favorites or bookmarks or history and all that. If you want that stuff, you have to write scripts for it.

Until you want to implement something like a privacy button. It needs to clear the disk cache. It needs to clear the cookies. It needs to clear the autocomplete for the navigation bar. It has to delete the page history. But you don't want it to nuke your bookmark database, so you can't just make a "purge all". What's one thing for the user isn't one thing for the developer, which is why you end up building monolithical applications.

Yes, but

[mujadaddy]

Does it run on Windows?

Re:Could use a better name

[Bambi Dee]

It's pronounced "useable", I suppose?

Nitpicks

[SanityInAnarchy]

I like the idea, and I'd love to play with it a bit, but there are a few stupid design decisions:

Why don't you just use a reasonable config by default?

There really is no excuse for this. I mean, yes, I can understand where not everyone would want that "reasonable default", but that's why it's a default.

We don't want to store anything "automagically" in the users home. Some people prefer different file/directory layouts

Uhm... ~/.uzbl? How difficult is that? And if you don't like it, rm -rf ~/.uzbl!

Or just create an example script that sets up the default config, and put it in your FAQ.

We considered the option of having a global '/etc/uzbl' which user specific ones could override but that would overcomplicate things.

I'm sorry, but even mplayer is officially friendlier than uzbl. How the fuck is it "complicated" to read one config file, then another?

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.

So, why doesn't uzbl also support these options? I'm using KDE, so Qt makes sense.

Uzbl.run( )
command is any uzbl command as defined above
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.

They obviously realize that JS runs in a single thread. So the obvious implementation here would be to use a callback, not a return value, so you don't block the entire page while you run that script.

I mean, I want to like it, but that's a number of facepalms right off the bat, so I think I'll stick with Chrome until I have time to fix them.

dupe!

[CODiNE]

http://slashdot.org/article.pl?sid=98/02/24/114700

11 year old dupe article.

Hmmm... as an aside... wonder why no posts there.

wget?

[Joe Mucchiello]

If it does more than wget, doesn't that mean it already has too many features?

Re:New name

[techprophet]

It's not being marketed. At all. STFU and go back to Firefox. This isnt for the masses. It's for us geeks who like slender forms.

I thought that would be called "Emacs"! ;)

[Hurricane78]

On a more serious note:

Why is it, that all the GUI desktops abandoned Unix's philosophies completely and instead went the Windows way (which of course actually is the MacOS/Xerox/$otherProductItGotTakenFrom way)?

I mean, imagine how great it would be, if we had all the tools of Gimp, Openoffice, Firefox Add-ons, etc, as separate entities, only bound to a document / data trough its mime type. You could mash up and reconnect everything at will. Pipe stuff trough that wizard, and then trough that.
Or connect a OOo tool and a Gimp tool trough pipes, and then draw with them, etc.

Imagine it like this:
- A global toolbox with all the
    - tools (something you "draw" with),
    - wizards (something that you apply to the selection/document) and
    - views (a view and controller for the model [file]).
- A window for every view of a file.
- A location bar, showing the current position/selection as an XPath.
- A properties box, showing all the properties of the current element/selection.
- The things in the toolbox would itself be normal files -- scripts or libraries implemented in every language with an API for it to be exact -- that you could show in views, edit with the properties box, apply wizards and tools to, etc.
(Yes I got to this ideas a long time ago. I just got no time or money to implement it. If you do, please tell me. )

You could build your own tools like with shell scripts. And because that would make it much easier to create new apps by slowly growing them, we would get much more innovation.
Also it would pose no problem for those noobs who dislike the shell for no reason. :)