• Welcome to the Off-Topic/Schweb's Lounge

    In addition to the Mac-Forums Community Guidelines, there are a few things you should pay attention to while in The Lounge.

    Lounge Rules
    • If your post belongs in a different forum, please post it there.
    • While this area is for off-topic conversations, that doesn't mean that every conversation will be permitted. The moderators will, at their sole discretion, close or delete any threads which do not serve a beneficial purpose to the community.

    Understand that while The Lounge is here as a place to relax and discuss random topics, that doesn't mean we will allow any topic. Topics which are inflammatory, hurtful, or otherwise clash with our Mac-Forums Community Guidelines will be removed.

Sheets as children of sheets?

F

Fred Gibbons

Guest
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.
 
Joined
Jun 6, 2006
Messages
1,153
Reaction score
94
Points
48
Your Mac's Specs
MacBook 2.0GHz White, 512MB RAM, 60GB HDD
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! :)
 
OP
F

Fred Gibbons

Guest
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)
 
Joined
Jun 6, 2006
Messages
1,153
Reaction score
94
Points
48
Your Mac's Specs
MacBook 2.0GHz White, 512MB RAM, 60GB HDD
Fred Gibbons said:
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.

Fred Gibbons said:
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.

Fred Gibbons said:
(There. You need a stiff drink if you just read all that)

Good idea ;)
 

Shop Amazon


Shop for your Apple, Mac, iPhone and other computer products on Amazon.
We are a participant in the Amazon Services LLC Associates Program, an affiliate program designed to provide a means for us to earn fees by linking to Amazon and affiliated sites.
Top