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."
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.
http://sourcemage.org/ - Have fun
About damn time, I say. For the past few years I have browsed the web with hundreds of tabs at a time. Firefox tends to crash after 50 tabs. Opera tends to crash at about 450 tabs. Some of this varies with RAM, but we're all familiar with the firefox single-thread issues, which really puts a downer on things. Let the window manager do its job: tabbing is for losers. Also what's with the insistence on keeping all tabs in RAM anyway?
.. in particular, I hate the web, surfraw is great, if it only worked. Web scraping utilities don't always work because webmasters insist on changing layouts, templates, HTML, and don't understand how to make long-term APIs for their content. So, my plan is to make something like xpather (from firefox) that allows a user to select elements on a page and figure out the xpath to retrieve the data. This can be dumped into a standard scraper definition file format or something, and then uzbl only has to pop up whenever some idiot changes a web page. Until then, these scrapers harvest data for me.
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.
Does it run on Windows?
Populus vult decipi, ergo decipiatur...
"Force shits upon Reason's back." - Poor Richard's Almanac
It's pronounced "useable", I suppose?
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.
Don't thank God, thank a doctor!
http://slashdot.org/article.pl?sid=98/02/24/114700
11 year old dupe article.
Hmmm... as an aside... wonder why no posts there.
Cwm, fjord-bank glyphs vext quiz
If it does more than wget, doesn't that mean it already has too many features?
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.
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.
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.
Any sufficiently advanced intelligence is indistinguishable from stupidity.