Eclipse on Cocoa now full of sheet!
Ok, we are crazy but you have to live on the edge every once in a while to prove that you are still alive. Therefore, as part of the polish pass for Eclipse 3.5, we implemented Mac sheet windows.
A sheet is a temporary dialog that is attached under the title bar of the parent window like this:
The idea behind a sheet is that the parent window and the sheet are tightly coupled and won't get lost in the window stack. On Windows and other platforms, this is achieved by bringing all windows that are blocked forward, along with the dialog, when the user clicks on either the dialog or a blocked window. With a sheet window however, there is no visual confusion or mess on the desktop. The sheet is contained within the parent window.
When sheets were first introduced on the Mac, they frustrated me. They appear with a wondrous sliding animated fanfare (whoosh!), prompting me while simultaneously blocking the content I need to see to answer the prompt. Thanks a lot! At the time, I considered this a typical case of style over substance but since then, I have lightened up and just hit cancel like everyone else.
When is a dialog a piece of sheet?
At first we thought that all dialogs were sheet, but we were wrong. There are dialogs in the world that are not sheet, for example, wizards. Then we thought all message boxes were sheet, but that was wrong too. A message box that warns of a preference change and offers to restart Eclipse is not sheet.
Bottom line: You need to decide which of your dialogs are sheet. Eclipse can't do it for you and neither can SWT.
To implement sheet, we added a single style bit SWT.SHEET that you can set on a dialog when it is created. This is typical SWT: a tiny API exposes tons of functionality. For example, the underlying Cocoa API for sheets has a special API to hide and show sheets rather than overloading the regular window hide and show API. We chose to use a style bit and keep the Control.setVisible() API the same.
Steve
A sheet is a temporary dialog that is attached under the title bar of the parent window like this:
The idea behind a sheet is that the parent window and the sheet are tightly coupled and won't get lost in the window stack. On Windows and other platforms, this is achieved by bringing all windows that are blocked forward, along with the dialog, when the user clicks on either the dialog or a blocked window. With a sheet window however, there is no visual confusion or mess on the desktop. The sheet is contained within the parent window.
When sheets were first introduced on the Mac, they frustrated me. They appear with a wondrous sliding animated fanfare (whoosh!), prompting me while simultaneously blocking the content I need to see to answer the prompt. Thanks a lot! At the time, I considered this a typical case of style over substance but since then, I have lightened up and just hit cancel like everyone else.
When is a dialog a piece of sheet?
At first we thought that all dialogs were sheet, but we were wrong. There are dialogs in the world that are not sheet, for example, wizards. Then we thought all message boxes were sheet, but that was wrong too. A message box that warns of a preference change and offers to restart Eclipse is not sheet.
Bottom line: You need to decide which of your dialogs are sheet. Eclipse can't do it for you and neither can SWT.
To implement sheet, we added a single style bit SWT.SHEET that you can set on a dialog when it is created. This is typical SWT: a tiny API exposes tons of functionality. For example, the underlying Cocoa API for sheets has a special API to hide and show sheets rather than overloading the regular window hide and show API. We chose to use a style bit and keep the Control.setVisible() API the same.
Steve
posted by Steve at
5:45 PM
|
17 comments
