Meet Uzbl — a Web Browser With the Unix Philosophy 318
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."
Really fun browser (Score:3, Interesting)
About damn time (Score:2, Interesting)
I've been working on some scripts to use with uzbl
Then all of us web-haters can send these xpath scraper template files around and live in harmony, or something.
Yes, but (Score:2, Interesting)
Re:Could use a better name (Score:4, Interesting)
Nitpicks (Score:5, Interesting)
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! (Score:4, Interesting)
http://slashdot.org/article.pl?sid=98/02/24/114700 [slashdot.org]
11 year old dupe article.
Hmmm... as an aside... wonder why no posts there.
wget? (Score:3, Interesting)
If it does more than wget, doesn't that mean it already has too many features?
Re:Reinvent the browser again? (Score:1, Interesting)
Actually, I was thinking about ripping out functionality from the browser and putting it into the desktop environment recently.
The idea I was considering is that what is today the window manager, in addition to window decorations, also provides an address bar and back/forward buttons for every window, based on a VFS.
Applications implementing content rendering slaves are loaded into those windows. They don't need to handle networking, tabbing, history or anything like that themselves, the desktop shell takes care of that. Starting a new application, instead of activating a launcher like today, would look more like opening a tab in Chrome - you get a window with some app chooser inside, when you choose an app it replaces the contents of the window.
It has some far reaching implications, like possibly giving local applications their own URIs (ie. app://openoffice.org?file=foo.odt), so the window manager was able to open a previously navigated away from slave application.
Anyway, just an idea.
Re:New name (Score:2, Interesting)
Re:Really fun browser (Score:5, Interesting)
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 (Score:5, Interesting)
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.
I thought that would be called "Emacs"! ;) (Score:3, Interesting)
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.