I have an app where each window has a primary document (an image). It
also supports the ability to open other images in separate panes (in
split views).
Remember, 'document' does not necessarily equal 'window'. A single
document may be displayed in any number of windows; conversely, a
single window may display multiple documents. As long as you've
already implemented your own window management code (rather than
using Cocoa's basic built-in behaviour), you can completely go to
town here.
Assuming that 1 document always equals 1 image (which your post seems
to indicate), what you want is to expand the View layer's scripting
support to provide the user with greater control over how those
documents are subsequently displayed on screen.
The 'open' command should always create a new document object
corresponding to the given image file. You should add to it an
optional 'at' parameter (similar to the 'at' parameter in the 'make'
command) that takes a reference to an existing window object. By
default, 'open' should automatically create a new window for
displaying that document. However, when a window reference is given,
the 'open' command should automatically create a new pane in the
target window and display the document in that.
(You might also map the 'aevtodoc' event's 'subj' attribute to your
'at' parameter, so that 'tell window 2 to open myFile' will have the
same effect as 'open myFile at window 2'. It's not essential though.)
In addition, you should define a 'pane' class as an element of the
'window' class, replacing its default 'document' property. The 'pane'
class should define a 'document' property containing a reference to
the document it's displaying.
If you want to give the user finer-grained control over where panes
are created, you could also allow the 'open' command's 'at' parameter
to take an insertion location to a window's 'pane' elements, e.g.
'open theFile at after pane 1 of window 2'.
Depending on how users interact with window panes, you may even
consider implementing a full range of commands for manipulating
'pane' elements: 'make', 'move', 'duplicate', 'delete', etc.
(Incidentally, it'd be real handy if Apple would fix Safari's AEOM to
support panes, as it'd provide a perfect example for folks to follow
when developing multi-pane apps. You might file a feature request on
that.)
