New To Mac-Forums?

Welcome to our community! Join the discussion today by registering your FREE account. If you have any problems with the registration process, please contact us!

Get your questions answered by community gurus Advice and insight from world-class Apple enthusiasts Exclusive access to members-only contests, giveaways and deals

Join today!

 
Start a Discussion
 

Mac-Forums Brief

Subscribe to Mac-Forums Brief to receive special offers from Mac-Forums partners and sponsors

Join the conversation RSS
Schweb's Lounge Forum for general conversation, chit chat, or most topics that don't fit in another forum.

Sheets as children of sheets?


Post Reply New Thread Subscribe

 
Thread Tools
Fred Gibbons
Guest
 
Posts: n/a

This one puzzles me: Apple decree that a sheet window may not spawn a sheet window. I have seen it done, in Ircle under Puma, so the GUI does or, at least did, permit it. But it's now prohibited behaviour. But I don't understand why.

Something that I didn't realise until recently is that sheets are nothing new. For as long as OS X has been around, Windows has supported a superior version of sheets. Go into any single-process SDI Windows app (e.g. Windows Explorer or Firefox), open several windows, and open a dialog from one of them. All other "document" windows (I prefer the term "task window") are still fully accessible. Outlook Express does not work this way, which in the past I have found as an annoying surprise.

Along come Apple's sheets and we suddenly think this is a new idea! But sheets are less useful. For example, try this in Windows Explorer:
  • Open two windows
  • In one of the, go to Tools > Folder Options, File Types tab, click Advanced, then New, then Browse. You now have a local chain of five windows.
  • Switch back to the other window. Note how none of the dialogs gets in the way!
  • For kicks, open Tools > Folder Options from the other window too.

Sheets are a very restricted version of this behaviour, with time consuming animations. One advantange of sheets is that the the parent and child windows lock together, with the parent window remains movable and minimisable. But these benefits amount to naught as soon as you need a child sheet which must be shown as application modal, whereupon the dialog locks out the rest of the app.


I've been maintaining a Mac OS 9/X/Win32 app (or two) for years and I have never used sheets before -- it's never been an option. I'm contemplating using them if I can find a way to use semaphores to lock up my parent window code to simulate the normal modal dialog behaviour of the parent being frozen pending the dialog's dismissal.

But my app has dialogs that spawn dialogs that spawn dialogs. There are certainly advantages to not using sheets: most of them are not dynamic dialogs powered by a data manager and trying to open two simultaneous copies will rapidly desynchronise and mutually delete each other's view of the data. (Only those parts of the app that need to be live across all windows are live, right now). To use window-modal sheets would require a manager for every other data type and other checks to make sure you don't cause conflicts! (Above, I showed that you can open Folder Options twice in Windows Explorer. Somehow I don't think that actually using Explorer that way is wise, I doubt it has dynamic management to post updates from one window to all other open instances and you could potentially lose changes.)

But it got me wonder about how sheets should work. Why can't a sheet spawn a sheet? Is there a rule against this? Apple's typical arrogance? Is it because sheets have no title bars and people would get confused as to what the current sheet does? (No idea why sheets can't have captions... Seems logical to me, but again, Apple don't agree.)


For those who are aware that I'm also attempting to design a GUI protocol for Cy/VOS, it has interesting implications for how I permit dialog boxes to work ...

I also wonder, just out of curiosity: for how long has Windows permitted sheet-like behaviour? Since 2000? Since 98/NT 4? Since 95? It's something so natural that you don't even notice it until someone like REAL Software (with their runtime) or Microsoft (with Outlook Express) go and break it.

I wonder who had the idea first? The scary thing is that it's a perfectly natural consequence of the single-process (visual only) SDI approach Microsoft took with Windows 95. (Apple's approach is still more on the MDI side of the fence, Windows apps are more on the SDI side of the fence although both OSes use a version of single-process (visual) SDI with notable exceptions like Windows Media Player 6 which is pure SDI -- one process per window. This is very tricky and avoided for obvious reasons.)

Oh, and hello.
QUOTE Thanks
cazabam

 
cazabam's Avatar
 
Member Since: Jun 06, 2006
Posts: 1,153
cazabam is a glorious beacon of lightcazabam is a glorious beacon of lightcazabam is a glorious beacon of lightcazabam is a glorious beacon of lightcazabam is a glorious beacon of lightcazabam is a glorious beacon of light
Mac Specs: MacBook 2.0GHz White, 512MB RAM, 60GB HDD

cazabam is offline
I've never used (or, to be honest, heard of) sheets, but I was confused initially by your use of the terms 'SDI' and 'MDI'. In Windows terms (I've been a Windows dev for years, for my sins) SDI means a single 'document' per window, not a single window per process. MDI, similarly, is allowing multiple documents (in sub-windows) per window. Word is SDI, as a new window is opened for each document.

Windows has no particular limit on the number of windows per process. Modeless dialogs are trivially easy, and modal dialogs only lock their parent window. How does this differ with sheets? Is it not possible to spawn a child window attached to its parent without causing it to be modal?

Oh, and hello!
QUOTE Thanks
Fred Gibbons
Guest
 
Posts: n/a

cazabam,

Well, there are two ways to do SDI: do you have a single process per document (I consider this "pure"; examples are Notepad and Windows Media Player 6) or one process running all the windows? There are advantages and disadvantages to both sides. I don't like the terminology anyway since many applications don't deal with "documents" -- Calculator for example. Firefox is MDI by definition but the interface is SDI and window-modal: tabs cannot spawn local dialogs (a failing by some accounts). Windows (or Mac OS or KDE or GNOME) has no awareness of what pages Firefox has open. There is no standard way to script tabs in AppleScript since they don't exist in the AppleScript Object Model.

The definitions of SDI/MDI are but one facet in a larger world of complications. The consensus that some of us have reached is that tabs should be known to the GUI. I go as far as to believe that container windows should be a higher windowing service, such that a program that uses tabs simply creates sub-container objects: { document space window handle, menu bar handle, { toolbar handle, ... }} and then forwards this to the low-level window manager (LLWM) for display. The program's initialisation instructions to the LLWM, overridden if necessary by customisations set at the user window environment level, define where that gets created: a new window, a tab in a window of the same process, a tab in a window of the same application (one process per tab, sharing a window, good for simple apps or where you want ultra security against software flaws) or simply shared with another window of a totally different application. SDI and MDI are now obsolete notions.

And why tabs? Opera is an example that proves my own point (I discovered this feature afterwards): Opera operates as both MDI (parent/child windows) and tabbed according to what you want. But there's also tiled: tile all the child windows as panes. MDI (parent child) is also an accurate description of an overlapping desktop and as such, you can do some fastastic abstractions with all of this and produce a relatively small set of window styles that describe the whole window environment at every level collectively.

Sheets, see Apple Human Interface Guidelines: Dialogs. They're window-modal dialog boxes that are spawned as a separate layer of the same window (but may extend past the side and bottom borders of its parent); they thus have no title bar and cannot, as such, have children, although I dispute this.

There are some clues on that page as to using sheets vs modal dialogs but I am not sure even Apple obey their own guidelines ...

It helps to understand that the Mac is MDI: that is, all the windows of the program live in a single layer and dialogs are all application modal. As of Mac OS X, you can interleave the windows with those of other processes but dialog boxes are still application modal. Windows SDI is window-modal: it's rare to see any decent Windows app open a dialog box that blocks another "document" window of the same process. On the Mac, this is normal. So then Apple decided that preferences dialogs should be modeless (and changes take effect), and if possible, dialogs should be shown as sheets to make them visibly window modal.

(Anyone who's reading this line: half way there!)

But you do get bizarre consistency problems. If a Preferences window needs more space, it opens a sheet. The sheet has OK and Cancel on it. These changes are not live. So why does the main Preferences dialog which is live and modeless, spawn sheets which are window-modal and have OK and Cancel?

Some people like the late Jef Raskin consider such ideas virtual silver bullets: get rid of mode and programs are now really easy. Except you create some heinous conflicts. And "modeless" dialogs are not modeless anyway. Who has the window focus? Who has the keyboard focus?

(Anyone who's reading this line: 3/4 done, the tunnel has a light!)

NeXT tried going modeless with their property windows (link is to the Apple HIG) and those are really confusing. They drive dragonman up the wall even more than they do me, so I know it's not just me. These cases are really more about relearning. For example, to close a Font palette, I think all you need do is press its keyboard shortcut again. But where is the focus? Modeless windows are horrible at letting you lose track of where the focus is.

If you really believe in the death of mode, I seriously recommend you look at Jef Raskin's Archy interface and play with it. See what you make of it. Lots of people seem to take it very seriously and you might find that it suits you. PC users must have a right alt key (not alt gr) since the UI is not designed for any real PC keyboards right now.

But I feel myself that there are no silver bullets. At every level of communication: machine-machine, human-machine and especially human-human, there are unsolvable conflicts. And we can but live with what those who are in charge have decreed for us, be that the Redmond folk or the Cupertino folk, or whoever wrote the X11 toolkits you use.

My only goal is to help design, for Cy/VOS, a UI layer that abstracts these decisions far enough that the user chooses. But the ramifications of modal vs modeless for programmers are very extensive in some cases.

(There. You need a stiff drink if you just read all that)
QUOTE Thanks
cazabam

 
cazabam's Avatar
 
Member Since: Jun 06, 2006
Posts: 1,153
cazabam is a glorious beacon of lightcazabam is a glorious beacon of lightcazabam is a glorious beacon of lightcazabam is a glorious beacon of lightcazabam is a glorious beacon of lightcazabam is a glorious beacon of light
Mac Specs: MacBook 2.0GHz White, 512MB RAM, 60GB HDD

cazabam is offline
Quote:
Originally Posted by Fred Gibbons
Sheets, see Apple Human Interface Guidelines: Dialogs. They're window-modal dialog boxes that are spawned as a separate layer of the same window (but may extend past the side and bottom borders of its parent); they thus have no title bar and cannot, as such, have children, although I dispute this.
I know exactly what you mean now. Yes, they are a weird one. They clearly can't be modeless - that would make no sense, but tbh I don't really like them. I'd rather have either a property pages style thing (similar to a tabbed set of sheets in Window, or (for example) System Preferences in OS X) or a proper dialog.

Quote:
Originally Posted by Fred Gibbons
But I feel myself that there are no silver bullets. At every level of communication: machine-machine, human-machine and especially human-human, there are unsolvable conflicts. And we can but live with what those who are in charge have decreed for us, be that the Redmond folk or the Cupertino folk, or whoever wrote the X11 toolkits you use.
Absolutely - one of the advantages of the OS X method is the clean separation of 'Application' and 'Window' (i.e. alt-tab, hiding, etc happens at an application level, minimising happens at a window level). Some may say it is a failing for the same reason.

Quote:
Originally Posted by Fred Gibbons
(There. You need a stiff drink if you just read all that)
Good idea
QUOTE Thanks

Post Reply New Thread Subscribe


« Google Video Player for Mac | Cool Links? »
Thread Tools

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off
Forum Jump

Similar Threads
Thread
Thread Starter
Forum
Replies
Last Post
Problem with Style Sheets in Quark4 macall Running Windows (or anything else) on your Mac 1 03-03-2004 08:54 AM

All times are GMT -4. The time now is 09:22 AM.

Powered by vBulletin
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
X

Welcome to Mac-Forums.com

Create your username to jump into the discussion!

New members like you have made this community the ultimate source for your Mac since 2003!


(4 digit year)

Already a member?