Robert, I agree that this is a conundrum. :) We are facing the same decision that had to be made for OpenStep on Windows. I really believe that we should choose an approach similar to the one that NeXT took at that point. I would be very skeptical of an MDI based approach, but I might be open to providing it as an option, if someone can show me that it's a viable approach for GNUstep apps. What concerns me about MDI are the modifications that would be necessary in the backend to support it... as well as possible impacts on the API to accommodate the concepts having subwindows (which MDI uses) would introduce.
I didn't say I liked the idea of MDI, just that it would be what I would expect to see in a Windows app in this situation. :-)
I believe there's a very good reason for that... Windows originally needed to "embrace and extend" a bucketload of applications ported over from other environments where the menu-per-window nonsense didn't exist and didn't make sense. These would be applications from DOS, Macintosh (including what would become Office and Works), etc. More importantly, the users needed to follow and Windows needed to provide for their habits --many DOS applications had built-in "window" management via menu accelerators, or the Borland-style top-of-screen horizontal menu across all of the windows when you hit F10, etc. Not to mention Mac apps had a single, shared application menu and (at the time) application-centric window focus policy. If you were Aldus getting ready to port PageMaker and FreeHand from the Mac, MDI would easily have deferred a complete GUI re-think, as well as a total rewrite of documentation and training materials. So, MDI let foreign menu and window policies be safely shoe-horned into Windows. It is the same problem, and therefore what I would expect to see on Windows in this case.
--Robert |