CLIM mail archive


RE: multiple application frames

  Has anyone on this mailing list designed applications which utilize multiple
  application frames whose commands may interact with one another? I would be
  interested in recomended ways to approach these types of applications with
  CLIM. In a simple case, a command defined on one application frame results in
  a request for a change of state of another application frame. In a more complex
  case, part of the command sentence on one application frame depends on
  information that is presented in another frame.


  Don Hamilton

This is a very useful technique.  We have used it heavily in CLIM 0.9,
though I'm not sure about its status in clim 1.0 or (future) 2.0.

We have designed interfaces using a style of interaction where one frame
is "master" and runs the top-level command loop for everything.  It may
launch "slave" frames in response to user commands.  A slave frame is
a frame with no associated process and thus no command loop.  Presentations
on the slave frame get highlighted according to the current input context
on the master frame.  Therefore the command table associated with the
master frame must "inherit" all the command tables of the slave frames.
The technique has to be used carefully, however, because the protocol
for frames and command loops wasn't designed with this in mind, and
certain styles of command definition must be avoided.

This type of interaction is much like the desktop and its
folders on the MacIntosh.  You get a pile of folders in response to
user commands, and they can be individually repositioned or hidden
or killed depending on what the user is interested in.  We use slave
frames for certain types of displays, such as graphs and tables.
It gives the user a great deal of control over the layout of
the screen.

Perhaps the ILA folks can comment here about their plans for 
master/slave technology in CLIM 1.0 and 2.0.  

jeff morrill

Main Index | Thread Index