I’ve had it.
I’ve used OmniWeb 5 for over five years. It was announced just over six years ago. It’s a web browser — six years! That’s more time than passed between Internet Explorer 6 and 7.
The reason I keep using it is because it’s wonderful, and the reason it’s wonderful is the terrific user interface. It doesn’t have much of a muscle elsewhere. Six years ago, it was the first in line to duct-tape a forked version of WebCore, then the only open source part of the WebKit effort, into a usable rendering engine. Now, it gets by on a slightly modified and periodically resynced WebKit fork.
I have written at some length about exactly what I like with OmniWeb and what I don’t like about The Omni Group’s stewardship — thoughts that The Omni Group CEO Ken Case at least partially agreed with. (If you want to know exactly what I like about it beyond retention of state and thumbnail tabs done right, read the post.) What has transpired since that post is that OmniGroup has become even more successful with even more apps on even more platforms and are now both more thinly stretched than ever and less likely than ever to care for renewing an OmniWeb commitment.
Something else that’s happened since then, though, is that the biggest impediments for technical progress are gone or rapidly disappearing. Out-of-process plugins are already implemented in 64-bit WebKit, and the new WebKit2 effort to provide a better, unified and non-blocking API makes out-of-process rendering separation not only possible but built-in (eventually).
There’s no time like the present to announce Rouse.
Rouse is an attempt to create a new Mac OS X web browser that steals the best bits from OmniWeb for its user interface, adds some well-needed hooks to the interior to customize rendering and loading, and otherwise stays away from scope creep as far as possible. It is an open source project doing the sort of thing that open source projects have proven to be enormously successful at.
I’ve spent some time the past few months making the idea gel, and it seems to me that while it’s not trivial work, it’s also not impossible, and it’s work that’s easy to specify. The hard problems of constructing a WebKit browser have fundamentally been solved by previous projects like Shiira, which is available under the same three-clause BSD license that Rouse will be. Until we get to the innovative part, what remains is simply labor.
There are a thousand questions you might want to ask about this, and I’d be happy to take them here or in the Rouse discussion list. For now, I’m attacking some of them here:
I’m actually very interested in this as I’ve been thinking about trying to build a Cocoa WebKit browser for some time but have been put off by my lack of familiarity with XCode and Obj-C.
What I would most like to see is a iTunes-like page for tab organisation that enables you to see various attributes about open tabs (URL, title, time loaded, etc.) and would enable you to sort tabs by these attributes. For example: you could sort tabs by their URL to group tabs from the same domain together, group tabs by time created to get a similar view to the default tab view on most browsers, sort by last reload to see which tabs have received recent attention, etc. This would be particularly useful for people who have their browser reopen with all the tabs from the previous session still open and are prone to spawning large numbers of new tabs very easily.
This probably wouldn’t really be feasible in an egalitarian browser, but I think it could be very useful in a functionalist browser in that it enables the user to deal with a large amount of information and choices without hobbling through an interface metaphor meant for use with a much smaller number of tabs.
I also think you’re picking an excellent time to do this with the impending WebKit2 engine and post-Chrome browsers.
By daragh · 2010.04.18 21:46
I think I have 170 tabs open right now. I know what you mean, I know what you want, and I want desperately to crack that nut to the same extent that you do.
By Jesper · 2010.04.18 21:48
And just to be clear, WebKit2 is not a new engine, it’s a new set of APIs. The goal is that the underlying WebCore, doing most of the rendering nitty-gritty, shouldn’t change that all to enable extending the better and more flexible programming practices that’s the point of the project.
By Jesper · 2010.04.18 21:58
This is a great idea. I would really like an option to autohide the browser chrome, like Quicktime X. Would that be doable?
By Dylan · 2010.04.19 05:33
The way I use OmniWeb today, only three things are constantly in view: the title bar, the tab drawer and the status bar. (Also the web content, but I assume you’d include that.) Even if it didn’t autohide everything it’d be pretty close.
By Jesper · 2010.04.19 06:19
Regarding content hiding, I’ve long wished that Safari had a standard toolbar show/hide widget which affected all the hideable chrome at once. Simple, unobtrusive, and largely consistent with the normal meaning of the control.
By Jens Ayton · 2010.04.19 18:05
KISS.
Job #1 is a browser that allows folks to have tons and tons of backgrounded tabs that don’t suck up valuable resources.
That’s why I’m still on OmniWeb.
Javascript disabled for the default page (with site-specific exemptions). Plug-ins disabled for the default page (with site-specific exemptions).
Make it use modern engines. Get it into circulation. Don’t worry about re-creating the browser interface until you’ve done that. Don’t worry about wish lists until you’ve done that.
(Now that I’ve said to avoid wish lists, my wish list is a simple web page text search of all of the backgrounded tabs I have open…)
By Chucky · 2010.04.19 23:57
The search thing is not a half bad idea. (It is in fact entirely bad, I did not proceed to say.)
I’m with you on resource usage. I fully intend to port site preferences fairly early on although not necessarily straight out the gates. I’m not with you on circulation. As far as this project goes, I’d rather be the only one using the browser of my dreams than need to tend to the needs of a user base whose vision is not compatible with my own.
It’s open for the simple reason that there may be others who want the same thing and want to work together in achieving it, and it’s open source because — actually, it’s open source because I like being able to release code, but a handy side effect of that is that people can fork it if they’d like.
By Jesper · 2010.04.20 00:06
“I’m not with you on circulation. As far as this project goes, I’d rather be the only one using the browser of my dreams than need to tend to the needs of a user base whose vision is not compatible with my own.”
Meh. You should want people to want this.
Think of Perian. Only 5% (?) of users have Perian installed, but that 5% needs Perian, are damn happy that it exits, and let the rest of the 5% know about it.
Don’t worry about the user base’s vision. Pump out a browser that your 5% user base needs, not the one they claim they need. With any luck, that will largely coincide with the browser of your dreams.
Even while coding to your own needs, you should want to be what users need. But more to my point about circulation, I’m just talking about getting out a stable beta on your own timeline, putting it on a webpage that doesn’t look like a code repository, and letting it find its audience.
“The search thing is not a half bad idea. (It is in fact entirely bad, I did not proceed to say.)”
Think of it as a specialized kind of history search, one informed by your own editing.
Say I’ve read this post, thought it was interesting enough to not close, but then 24 hours pass and it’s moved fourteen thumbnails up the tab bar.
I remember I read something interesting about “Omniweb” or “webkit” somewhere sometime, but if I dive into the normal history search, all the web pages I’ve consumed but not found worthy of preservation gum up my search results. Instead, I want to just search what I’ve found worthy of keeping open.
But that said, again, ignore wish lists. Keep it simple, and get it out into user hands.
By Chucky · 2010.04.20 00:34
I’m not saying I don’t want people to want this. I’m saying that if what people want clash with what I want, then I think I’m going to stick to my guns. Didn’t you just tell me twice to “ignore wish lists”? This is strongly related. My point was exactly that if I build something I would love, others would/may too. And for what it’s worth, it’s also still a theoretical situation.
Of course that’ll happen — in due time, when there is a stable beta. I don’t want to show off anything that hasn’t already materialized. The reason it looks like a code repository is because I’m interested in attracting people who like to contribute code to repositories. That’s where it is right now, and I need to be honest about that.
I knew exactly what you meant by the searching. I was being facetious.
By Jesper · 2010.04.20 01:03