Comments on: Why can’t Safari get tabs right?

By: Lars

Lars — Thu, 18 Jun 2009 16:52:27 +0000

Keywurl turns the Safari address bar into a omnibar, it’s what I used for Safari 4 Beta and before that.

By: José

José — Fri, 12 Jun 2009 14:58:32 +0000

Safari’s UI would actually look like Chrome if they had the same approach on the tabs…

By: Mohamed Mansour

Mohamed Mansour — Fri, 12 Jun 2009 00:51:16 +0000

Google chrome is a nice project, that is why I contribute to it since day one (and now a committer) MAC is still in alpha! Only the community can make it the best browser out there! http://blog.chromium.org/2009/06/plausible-promise.html

If all of us help it out :) The mac version will beat any browser out there !

By: Thom

Thom — Thu, 11 Jun 2009 13:23:12 +0000

Hmmm. Mostly agree with your subtle details comment. However, moving the tabs to a new location and orientation is not subtle.

By: Ken

Ken — Thu, 11 Jun 2009 12:01:32 +0000

It would be possible to visually reproduce the look of Safari 4 beta. There is one show stopper, however, for Java apps on the Mac: when you implement your own resizing mechanism (i.e. you call myFrame.setSize(…) in response to some event) there is a terrible flicker. This is why my HUD component in Mac Widgets for Java is currently not resizable. Hopefully this will get fixed soon.

-Ken

By: Jambo

Jambo — Thu, 11 Jun 2009 07:46:06 +0000

I totally agree. Very hard to mimic the Safari 4 interface in Swing because of the window title bar. This one is anyway tough: reproduce the “continuous” title bar in Swing as it is more and more used in Leopard is a real challenge. Especially if your app should be multiplatform.

By: David Qiao

David Qiao — Wed, 10 Jun 2009 19:52:06 +0000

I couldn’t agree more. The Chrome unified title bar approach is much preferred.

By: Ken

Ken — Wed, 10 Jun 2009 17:07:47 +0000

The tab overflow problem is a messy one. I hadn’t really thought about all the great points you make about selecting an “offscreen” tab via a menu. I’m not sure what the right solution is.

By: Harald K.

Harald K. — Wed, 10 Jun 2009 15:00:20 +0000

PS: Another important aspect of tabs-as-MDI, is overflow handling. I think the Safari 4 implementation makes sense (no scrolling, but keeping the selected tab visible on screen). Better than Safari 3 and Terminal at least (no scrolling + menu for overflow, making only the first tabs re-arrangeable).

Firefox uses scrolling + a menu, showing all tabs.

I’ve seen apps that re-arrange tabs to keep the selected tab on screen was well. The bad thing re-arranging is that the tab might not be where the user left it, when he wants to go back..

If someone has the perfect solution to this, please let me know. ;-)

By: Harald K.

Harald K. — Wed, 10 Jun 2009 14:46:33 +0000

Interesting.. Haven’t tried the Safari 4 beta myself (using Firefox 3), but I must say it *looks* great. As far as I can understand, mixing tabs/window title bar will only be a problem when moving the window vs re-arranging tabs… But I kind of think this approach makes sense for a tabs-as-MDI implementation. Chrome also makes sense, but looks less nice (less Apple maybe ;-) IMO.

I’m working on implementing a “tabs-as-MDI” or “browser tabs” component for Swing, and have currently implemented a hybrid between Safari 3 and Terminal. Implementing the look of Safari 4 should be doable, just more fancy effects.

But maybe I should implement something more like Chrome instead? The Safari 4 beta seems close to impossible in Swing, unless making the window undecorated and do everything by hand…