What are the various frame types for an RB Window?

| | Comments (22)

One question which I've seen asked, but I don't think is covered very well by the documentation is what the different frame types are for a Window object, and how they map from platform to platform.

So let's take a look at what each of the frame types look like on all three platforms.

0 - Document

This is, by far, the most common frame type in application. It's the default frame type which should be used when you want a modeless interface that has a titlebar and shows up in things like the taskbar.

Windows Document window Macintosh Document window Linux Document window

You'll notice a few things here. For starters, the Mac screen shot has no menu bar. That's because the menu bar on the Mac is global, located at the top of the screen, and not part of any window screen shots because it's not a window decoration. Aside from that, all three window behave in much the same fashion. They've got three widgets for adjusting the state of the window, they're all modeless windows, and they are typically the primary window for an application.

1 - Moveable Modal

A moveable modal dialog does exactly what its name implies. It's a modal dialog (meaning you need to show it with ShowModal instead of Show). But you'll notice that there's a pretty big visual difference between the windows. A moveable modal dialog on the Mac has no widgets to adjust the UI state. However, on Windows and Linux, these widgets still apply.

Modal dialogs such as the moveable modal are meant to display secondary information. So a primary window (like a Document window) will usually be the parent of a secondary window such as this frame type.

Windows Moveable Modal dialog Macintosh Moveable Modal dialog Linux Moveable Modal dialog

Another interesting property of a moveable modal dialog is that it will automatically disable the QuitMenuItem for that window. So on Windows and Linux, the Exit menu is disabled, and on the Mac, the Quit menu in the global menubar is disabled.

2 - Modal Dialog

The modal dialog is similar to a moveable modal dialog, except that it's not meant to be moved around.

This frame type applies well to all platforms, just like the document window or the moveable modal window.

Windows Modal dialog Macintosh Modal dialog Linux Modal dialog

In keeping with the moveable modal dialog, the modal dialog also disables the QuitMenuItem when it is shown.

3 - Floating Window

The floating window frame type is a different type of secondary window. It's a modeless window that "hovers" above all non-floating windows. This frame type is used as a way to always display information to the user no matter what window within your application is frontmost.

On Windows and the Mac, the window's titlebar is smaller than with document windows, but this visual distinction does not carry over into Linux. That's because Linux has no concept of a floating window. That means you cannot have a window that always remains in the top window layer for your application on Linux. So you'll probably want to avoid this frame type for your Linux applications.

Windows Floating window Macintosh Floating window Linux Floating window

4 - Plain Box

This window type corresponds to a window with no decorations. You'll usually see this used for things like splash screens on Windows and Linux (only the menu bar is usually removed for a splash screen).

Windows PlainBox window Macintosh PlainBox window Linux PlainBox window

This frame type maps nicely between all platforms, so it's safe to use it on any platform.

5 - Shadowed Box

To be entirely honest, I've never truly understood what this frame type should be used for. I am certain it's a hold-over from Classic. You'll notice that the UI looks completely different on all platforms. On Windows, it's a sunken look. On the Mac, it's got a heavy black border. And on Linux, it looks the same as a plain box. Because of this, you should avoid using this frame type for cross platform applications.

Windows ShadowedBox window Macintosh ShadowedBox window Linux ShadowedBox window

This is technically another modal dialog type (so you should use ShowModal when displaying it). Because of this, the QuitMenuItem is disabled when this window is displayed.

6 - Rounded Window

Here's another concept that I believe is a hold-over from Classic (but could be wrong on that). It has no equivalent on Windows or Linux. One the Mac, all rounded windows get a white background to them, and on Windows and Linux, the window is displayed as a regular document window.

Windows Rounded window Macintosh Rounded window Linux Rounded window

If you're doing cross platform development, you may not want to use this frame type. But because it maps fairly closely in everything but appearance on all platforms, it wouldn't be too terrible to make use of it.

7 - Global Floating Window

A global floating window does exactly as the name implies. It floats over all windows, regardless of which application is currently being used. So it always sits in the topmost window layer.

Just like with a regular floating window, Linux has no such concept as a global floating window. So if you're deploying to Linux, you may want to avoid using this frame type. It simply maps to a document window, just like a floating window does.

Windows Global Floating window Macintosh Global Floating window Linux Global Floating window

An interesting side note -- if you set MenuBarVisible = false, then your global floating windows will also disappear on the Mac. This is because a global floating window is considered part of the system UI, and that's what MenuBarVisible will hide or show.

8 - Sheet Window

A sheet window is a concept that exists only on the Mac. Basically, it's a document-modal window that is usually used to ask the user for simple user input. Things like "would you like to save?" or "are you sure you want to do that?" dialogs are best displayed as sheet windows on the Mac. You must display them with ShowModalWithin.

On Windows and Linux, they become moveable modal dialogs.

Windows Sheet window Macintosh Sheet window Linux Sheet window

Even though there's a fairly large visual difference between a sheet window on the Mac and on other platforms, it's usually ok to use them in a cross platform application. The meanings don't map perfectly though (since a moveable modal is application modal, not document modal), so watch out for that difference. But they map close enough, and are such a widely used (and accepted) Mac UI concept that it's hard to discourage their use.

9 - Metal Window

This disgusting UI concept exists solely on the Mac (sorry, had to let my bias show through there!). As the name implies, it gives the window a brushed metal look. In order to use one of these properly, you must set the Composite flag to true on the metal window.

Since this abomination does not natively exist on Windows and Linux, REALbasic maps a metal window to be a document window on those two platforms.

Windows Metal window Macintosh Metal window Linux Metal window

This frame type maps functionally across all platforms, so it's safe to use from that point of view. However, it does not map visually across the platforms, so be aware of that. There is one functional difference that I'm aware of: on the Mac, you can move one of these abominations by clicking anywhere on the window's frame itself (anything that's metal). This concept does not transfer to Windows or Linux.

10 - Drawer Window

Here's another Mac-only UI concept. A drawer window is one which "slides" out from an edge of its parent window. As such, it's a secondary window, usually used to display a list of some sort.

This frame type is very cross-platform unsafe. It maps to a floating window on Windows, and a document window on Linux. Because of this, you do not want to use this frame type for cross-platform development.

Windows Drawer window Macintosh Drawer window Linux Drawer window

That's the full list of the supported frame type enumerations in REALbasic. I also tried to let you know some of the little cross-platform gotchas with each frame type, but I'm sure there are some quirks that I've missed describing. Hopefully this gives you a little bit of insight as to what each of the frame types mean, and how they work on all platforms.

22 Comments

5 and 6 are definitely holdovers from Classic. For those who don't know, #5 was often used for about and splash windows, and #6 was the default UI for a desk accessory (think of the classic calculator in the Apple menu).

Ah, no kidding? That's what you use a rounded window for -- I always wondered that. I recall Joe mentioning that splash screens were usually shadowed windows, but (like many old concepts on the Mac we still support) I was lost about rounded.

Personally, I like the way that the Shadowed Frame looks on MS Windows.

I was also unaware that every frame type supports menus on MS Windows. I guess it strikes me as odd since I have never seen a menu in for example a Floating Window.

The shadowed frame look on Windows is a sunken window, which I've only seen used for things like EditFields. I'd never seen it used as a window frame type until I saw RB. :-P

As for menus, yes, you can attach a window to anything, with one huge exception: when you're application is an MDI application, the menu can only be on the MDI frame, or on a window not contained by the MDI frame (ie, floating windows). So that means the document windows in your MDI application cannot contain their own menus.

I think the metal windows look alright if you have almost no metal showing ;)

Personally, I can't stand the metal look. I think standard Aqua is very elegant and easy on the eyes. Sheets are very cool, and I've used a drawer in only one application, but it worked quite well in that case.

Sheets are one of the only innovative UI designs I've seen come out of Apple since OS X shipped. The concept of a document modal dialog which is physically attached to the document window in question is a great idea. So I personally like sheets.

I'm personally not too keen on drawer windows. I see them being abused way too often (most people tend to use them as a visual distinction between parts of a window, instead of what they're meant for). I think that metal windows are a visual abomination, and the fact that Apple has documented a certain use for them but never bothered to follow that guideline to any degree bothers me. If you're going to have a visually different interface for certain types of application (a silly idea, to be sure), then fine -- but follow your own damned rules. Otherwise you end up with abominations the like Finder.

You know what's worse? Apple trying to dupe the Metal Window look on their Windows apps *shudder*

I'll let that "sheets are the only innovative UI design" comment slide. Ok, I'll at least point out that I cannot live without Expose. I'll just leave it there :)

I will say, however, that, in my opinion, it is drawers that are the abomination and not metal windows. There is a problem with too many metal windows. It is the one thing I don't like about Safari and it is also something I don't like about Finder windows that are showing the toolbar. But I ALWAYS hide my Finder toolbars so that I don't have to look at metal windows and I'm fine. I think the iTunes and QT metal windows are fine.

Drawers, on the other hand, well, suck. I plan never to use them. I think Apple is moving away from them as well. Mail used to use a drawer to show all mailboxes and in Tiger it doesn't.

I realize now I misunderstood your point about UI design. Expose doesn't count because what you are talking about are UI elements that a developer can use in her own application. I'd have to give that a bit of thought, but I take back what I said about Expose.

@Will - Expose it neat, but I (personally) find it a poor replacement for multiple desktop support. But it was innovative (just not of the type I was talking about).

I agree, drawers are overdone and generally for the wrong reasons. I find them conceptually to be a not-to-shabby idea. But in practice (and a lot due to Apple's use of them), people misuse them and try to use them for things they shouldn't be used for. Then they become quite cumbersome and annoying.

Metals windows are simply ugly. The concept of having two different frame styles depending upon app use is simply stupid (it serves no useful purpose). So I find them to be an abomination in both ways -- theoretically and visually.

Exposé is not meant to be a replacement of multiple desktop support. They're completely different beasts.

If you want multiple workspaces download this: http://desktopmanager.berlios.de/index.php
It rocks, though I only use it on my laptop.

Drawers are useful though they're bad in RB.

Sheets obviously rock.

Metal windows are fine if used when it actually looks good. None of Apple's uses bother me.

Rounded and Shadowed windows could die when OS 9 support dies. No use on any of the platforms makes them silly.

Linux not having floating windows is weird.

Windows having close, maximize, and minimize buttons on *modal* windows has always been weird to me. It's a stupid UI design if you ask me. "Here's the Cancel and OK button, but there's an non-descriptive "X" up here as well...." Huh?

A question for you related to something in my current work: what kind of window do you guys use for the autocomplete list? On Mac OS X it seems like it's a plain box that's in a window group with shared activation with the main window, but what about Windows and Linux?

While I'm on the subject, haven't you ever noticed that the autocomplete list won't go away if you switch apps? It freaks out and will from then on always be visible.

>> Sheets obviously rock.

Did I ever mention that I really appreciate the new ShowModalWithin() method for the MessageDialog class?

@Seth -- I use desktop manager, and you're right, it does rock. But Expose, to me, is a way of organizing views on the fly. Which is the same thing (only weaker, since it's a static view) as virtual desktops. Don't get me wrong, expose is a neat little program! But I find it gets in my way (I am constantly accidentally hitting the F keys for it when using home or page up) and it's not powerful enough for my needs.

As for the autocomplete window, it's a floating window and we use a special MacProcID on the Mac (1040) and use declares to remove the titlebar and borders on Windows. I have no clue how it works on Linux (William would know, I'm sure).

And it sounds like what you've found is a bug with the autocomplete window. You should report it with steps to reproduce.

@Phil -- yes, that's a nice little feature. Much-needed for Mac users.

I use Expose to show the desktop, grab something, reshow all my windows, and then drop the thing I grabbed onto a now-visible window. I can't imagine how I ever lived without it. I also, occasionally, use Expose to show all my windows so I can pick one out. That's also very useful, but not something I use as much. You can also show just the windows of the current app, of course, but I think I pretty much never use that, mostly because I'm just not in the habit.

@Will: Yup. That's why I use it for also. Multiple desktops simply wouldn't ever make those easier. You might have less windows on a screen, but you'd still need to deal with moving between them all. Multiple desktops and Exposé would go hand in hand nicely.

@Aaron: You can always change the function keys. I have mine set to the two lower corners which is perfect for drag and drop, and since my dock is on the bottom (like normal people!) nothing inhabits those corners so I never/rarely(?) hit them on accident. Not that it interrupts anything.

Whoa! Since when has there been a plain box? That seems like it would solve my titlebar issues completely...

Since CrossBasic! :)

Hi Aaron,

Re type 3 floating windows: How do you deal with multiple of them? What is the ordering? Is it possible to change the ordering of floating windows?

That answer depends on the OS. I'm not sure about the Mac, but on Windows, whichever one is active is the frontmost one. Remember, since the floater can get the keyboard focus on Windows, it has an active state, so there is a "frontmost" floater concept. You can change the ordering by changing the order of calling Show on them as well as with declares.

OK. Thanks for the explanation.

Leave a comment

Disclaimer

I'm currently an employee of REAL Software. My blog is mine. The opinions represented in this blog are mine as well and may not represent my employer's opinions. All original material is copyrighted and property of the author.

REALbasic® is a registered trademark of REAL Software, Inc. REAL SQL Server™ and Lingua™ are pending trademarks of REAL Software, Inc. All rights reserved.