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:
I wonder if you can layer one sheet on top of another sheet so that you effectively end up with a pile of sheet?
By
Ed Merks, at 7:27 PM
Apple has thought of that. Creating a pile of sheet is against their user interface guidlines!
By
Steve, at 8:07 PM
great to see that SWT cocoa becomes better and better supporting all the mac-specific things.
thx for all your hard work on this.
By
ekke, at 12:46 PM
Fantastic! Now all that remains for a great SWT Cocoa experience is support for the native customizable toolbar.
Any possibility you might be able to implement that for 3.5?
Adding in this final feature would finally open to the door to implementing a complete native feeling app in SWT for Mac.
By
Anonymous, at 3:07 PM
Does this means, that SWT is going further away from "lowest common denominator" for all platforms?
By
Anonymous, at 10:28 AM
Anon-y-mouse,
First off, SWT can be thought of as "highest common multiple", rather than "lowest common denominator", which has negative connotations. Do do this, platform specific features such as sheets are made available using hints. For exmaple, on platforms other than the Mac, the SWT.SHEET style is honoured in a way that functionality is not lost. SWT.SHEET on Windows and elsewhere creates and positions a regular Windows dialog.
Finally, it is always possible to tell whether a hint has been honoured. In the case of the sheet, the bit is cleared on platforms where it is not supported.
By
Steve, at 10:43 AM
Unfortunately, the native Mac tool bar did not make it into Eclipse 3.5 and we are past API freeze.
By
Steve, at 10:46 AM
Fine!
That will give Eclipse an other advantage in fighting NetBeans... sorry... JDeveloper.
By
Anonymous, at 12:49 PM
thank you for this post, I enjoyed it very much.
By
b0b0b0b, at 8:57 AM
Not a Mac user but I think this looks great. Or more specifically, great to see us using a platform capability that adds that kind of polish and appropriateness for the platform. I think it's quite important.
By
Kevin McGuire, at 10:44 AM
I haven't yet lightened up and still don't like sheets because they hide part of the underlying window that I sometimes want to see -- perhaps someday I'll take a chill pill. But nonetheless, since this is a standard and useful part of the Mac UI, I'm glad to see you'e implemented it!
By
Mike Morearty, at 10:26 AM
This is awesome. Congratulations. I love your blog because I can learn about the challenges to create a great tool as SWT is. Do you think SWT on Cocoa will be stable enough for the next Eclipse Release?
By
adam, at 7:51 AM
Yes it is ready. Otherwise, it would say *early access* on the download page.
By
Steve, at 8:16 PM
I've noticed that using a combination of SWT.SHEET style bit with MessageBox and file/directory dialogs introduces some strange behavior; once a MessageBox is created with SWT.SHEET (and closed afterwards), file and directory dialogs become unresponsive, i.e. you can not close them by selecting a file and clicking OK, nor by clicking Cancel.
I call that sheet.
By
Anonymous, at 2:14 AM
That just sounds like a bug. I remember it happening and Silenio fixing it. If not fixed in the latest, please enter a bug for it ... and yes, it's sheet.
By
Steve, at 10:37 AM
Hi, Steve, I'm Anonymous (at 2:14 AM) and I reported a bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=287665 this morning.
I think that Eclipse 3.5 for Mac is otherwise great and I'm thanking you for your concern!
Best regards,
Albert
By
Anonymous, at 3:54 AM
Thanks Albert. FYI, I no longer lead the SWT team and have switched jobs, but still care about Eclipse and SWT.
By
Steve, at 7:01 AM
Post a Comment
<< Home