[EMAIL PROTECTED] wrote:
In a message dated 8/9/04 12:04:59 PM, [EMAIL PROTECTED] writes:
When we talk about "true MDI", are we talking about containing all of
the applications documents in a single window, rather than having each
of them as an independent window?
-- Well, ask a Windows developer what kind of MDI support is wanted in RR. As
for me, I want a clean and effective way to handle MDI so it works like a MDI critter in Windows expected. Anyone have a code library for handling MDI on Windows with proper support for the taskbar?
What are the concerns about the taskbar? AFAIK it's not possible to do MDI at all in Rev today, though there is a proposal for its implementation (see <http://www.runrev.com/revolution/developers/bugdatabase/show_bug.cgi?id=1928>).
What is MDI?
------------
The Win HIG describes four windowing models for desktop apps, each appropriate for different workflows:
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch10a.asp>
Single-Document Window Interface Workbooks Projects Multiple-Document Interface
Of these, Rev can do the SDI and Project models easily, and can mock up an acceptable Workbook with only modest effort to make tabs at the bottom of a window (I never use the Workbook model myself).
But MDI is a whole other animal, in which a parent window encompasses all document and tool windows. Ideally, tool windows are also dockable in a true MDI (though not a spec requirement). The parent MDI window holds the menu bar, unlike the SDI model in which each document window has its own menu bar.
There's an argument that MDI most closely parallels the Mac experience, since the Mac also has a single menu bar. But with the advent of OS X that's where the similarities end: in Mac Classic windows for a given app were in their own layer, and moving one forward brought all of them forward, which is what you get when moving an MDI window forward. But OS X now has interleaved windows, so that apart from having a single menu bar Mac apps generally have more in common with the SDI or Project models.
It's useful to note that MDI is for viewing multiple documents, and is not necessarily appropriate for all multi-window designs. Interfaces that provide multiple windows as different views into a single document file are addressed by the Project windowing model, which the Rev IDE uses.
Case Study: HyperRESEARCH
-------------------------
I have had only one app which would have benefitted from MDI, and the workaround is not pretty: make a detached toolbar/menu window and position it along the top, using the backdrop to hide other apps. That app (HyperRESEARCH) is most accurately described as a hybrid between this quasi-MDI model and the Project model (for viewing different elements of a single document we have one window for displaying transcriptions, another for cataloging citations of those transcriptions, another for listing the conceptual labels used for marking those citations, and another for annotations associated with the citations).
While HyperRESEARCH's design is inherently a perfect match for the HIG's Project model, users slammed us for not providing the conveniences afforded by MDI (rightfully so, IMO, even though we were fully HIG-compliant with the Project model). Our emulating some of those MDI appearances and behaviors was a response to those requests, chiefly that there be a way to hide other apps and to minimize everything at once.
The toolbar+backdrop kludge is a far cry from the useful behaviors of MDI, which include being able to have the MDI parent window not maximized so one can easily switch to other apps by clicking on them directly rather than relying on the taskbar alone.
Also, an MDI parent window will of course hide all of its sub-windows when minimized, but to emulate this behavior you'll need to trap the iconify message in the toolbar window and minimize all your subwindows in script, which results in each of them having their own tab in the task bar (MDI gives you just one tab for the parent window, keeping things simple and clean).
Moving Beyond MDI
-----------------
Since the advent of OS X I don't bother with emulating MDI, as it doesn't address interleaving for managing windows on non-M$ platforms. Instead, we're migrating HyperRESEARCH to a panelled design in which what were separate windows in older versions will become resizable panels in a single window (a la Outlook Express, Mozilla, iMovie, etc.).
In addition to simplifying the user's workspace, the extra benefit of migrating the former hybrid Project/quasi-MDI model to a panelled SDI is that we save a fair amount of screen real estate by not having all those window title bars (32px * the number of windows * the width of each). Also, having everything associated with a given file in one window allows us to have multiple windows open; in a Project model it would be difficult to keep track of which window is viewing which file.
One could argue that a panelled single window is the more modern alternative to designs that use multiple windows for different views associated with a single file. Apple seems to think so, with iMovie, iDVD, iPhoto, iTunes and others using mostly one window for everything, with the occassional dialog for less common tasks (I tend to design in ways that avoid platform-specific elements like Drawers).
While panels give you a better alternative to the Project model, they don't address those apps in which it's beneficial to have all documents together in the same application space (though I can't think of any offhand).
However, until we get a reliable method for notifying an app when a document is double-clicked (AFAIK Micro$oft provides no API for this, creating a second instance of the app instead), the usefulness of MDI is hampered. M$ suugests we use MDI where needed, but makes it unnecessarily difficult to do so. Fortunately it's not needed often.
Summary: Alternatives to MDI often make a cleaner UI
----------------------------------------------------
While MDI is sometimes useful and for the sake of completeness I feel Rev should support it, I prefer to use SDI for single-view documents and extend that with panels for replacing the multi-view Project model. True, M$ Office relies on MDI extensively, but application suites are a special case with unusually high needs for interaction among separate documents, and no one complains about Internet Explorer's cleaner and simpler SDI. And with OS X's interleaved windows Apple is leading the way with a trend toward panelled single-window interfaces on that OS.
SuperCard users like myself may find the transition from multi-window views to panelled views unintuitive at first, if only because SC does a fine job in supporting multiple windows (with some features Rev has yet to match, like having different tool modes for different toplevel windows) but provides no equivalent of Rev's group object needed for many panelled designs, such as those in which a given panel must be scrollable independently of other panels.
Andrew, does your app use multiple windows for separate documents, or for different views into the same document?
If the former you may find SDI sufficient, and if the latter you may find moving the contents of those auxilliary windows into groups within a single window will simply your user experience.
-- Richard Gaskin Fourth World Media Corporation ___________________________________________________ Rev tools and more: http://www.fourthworld.com/rev
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
