Safari 4 Beta: UI Disaster
Linked by Thom Holwerda on Sat 28th Feb 2009 11:47 UTC
Apple A few days ago, Apple surprised everyone by releasing the first beta of Safari 4, the company's latest version of their WebKit browser. While I generally love Safari on the Mac (my browser of choice on that side of the fence), I've never felt as comfortable with it on the Windows side of things. In any case, this latest beta has made a very bold move in the interface department, and I'm sad to say that it's not for the better. Let me explain where it went wrong for Apple.
E-mail Print r 13   · Read More · 84 Comment(s) http://osne.ws/g8w
Thread beginning with comment 351081
To view parent comment, click here.
To read all comments associated with this story, please click here.
ba1l
Member since:
2007-09-08

Err... Native controls in Windows certainly do have their own window, the same as they do in X.

In both systems, a window is simply a region of the screen, which can be drawn to, can receive events, and can have a parent window. The parent window may be the desktop itself (which is also considered to be a window).

The difference is that there are far more special cases in Windows than in X. Special cases in X only occur for top-level windows, or stuff like virtual desktops, and are all handled by the window manager.

In Windows, pretty much every type of control is a special case, which adds default behaviour and appearance. But they are all still windows.

Reply Parent Score: 3

OSGuy Member since:
2006-01-01

Yes you are right, with Windows, every control IS a window (this excludes the menu bar) but unlike X.ORG, by default "visually" it does *not* live outside the parent form (which is the case with X when you show the widget) that created the control (widget). With X.ORG, each control/window/widget can live outside the parent window (form) that created the widget. The Window Manager gives it a border so it is treated like another form (when speaking with Windows terminology). Thus, the "window manager should handle the tab bar logic".

With windows however it is a different story. Each newly created control must be assigned to a real window with borders or what we call a "form". Thus, the "window manager should handle the tab bar logic" is voided because visually, it is not a form.

Because of the way X treats controls, it makes it a bit difficult to create an MDI and not just that but if things get messy, you may end up with a task bar button for each icon on your desktop because each object in X is treated as if it was a form equivalent in Windows. So you have to do a few extra steps to make it behave the way you'd expect to.

As far as Safari is concerned, I trully doubt that's a real title bar. It's probably a panel aligned to the top and masked to look like a title bar. With Windows you can make the entire form behave like a title bar so it's not that hard.

Edited 2009-02-28 22:43 UTC

Reply Parent Score: 2