With Apologies to RJ - just can't quite feel the love or

[Chris Despopoulos]

RE the problem of nested windows when you OPEN ALL in a book...  The answer I got is, "Always expand docs to full screen -- use the tabbed interface."  

This is reasonable if you want your doc windows to always be fully expanded.  I use Maker documents as generated logs.  I personally don't want the the log file to take over the entire screen.  I guess what I have to do is display the log in an editable dialog box (logs need copy, at least), and not use FrameMaker.  Say goodbye to links into the user's documents.

I also use FrameMaker docs as a GUI for some plug-ins.  It's really a problem for me to convert those to dialog boxes...  I use tables, autonumbering, xrefs, hypertext, and other things that FrameMaker provides.  In fact, I see no reason that a GUI should *not* be built out of FrameMaker documents, effectively the same as HTML forms create a Web GUI.  But unless you want the GUI to be the entire screen, you can't get away with a Maker doc as a GUI.

RJ, I don't believe the API exposes much (or any?) control over the new windows -- for example, can I cause one window to be open at less-than fully expanded while others are fully expanded?  I beat my head against this wall during beta, and I logged the issue.  But I never heard anything about it.  As I recall, I logged other issues with the new windowing paradigm in the API... 

In my spare time (not!) I'm trying to devise workarounds, but you can see that they're prohibitive. What would be most excellent would be an API to create a pod or other GUI widget that wraps a FrameMaker document.  That's analogous to the old Pallette mode for a locked document.  Or analogous to popups in HTML.  Imagine how rich the GUI could be if it could include FrameMaker documents!  That's why I use FrameMaker as the GUI for TemplateMapper, for example...  It works very well.  I don't want to say goodbye to that capability.