CLIM mail archive
[Prev][Next][Index][Thread]

Re: Overlapping windows to CLIM application frameworks

  Date: Mon, 13 Jul 92 10:10:02 CDT
  From: owens@cs.uchicago.edu
  MMDF-Warning:  Parse error in original version of preceding line at BBN.COM
  To: clim@BBN.COM
  Subject: Overlapping windows to CLIM application frameworks
  
  ...

  Specifically, I want to present a list of objects in one of the
  application's panes. Each time one of the presentations objects is
  selected, I want to create a new window displaying detailed attributes
  of that object.  I want the freshly-created window not to occupy any
  of the application frame's screen real estate (it's ok for the new
  window to appear in front of the application frame, but it must be
  relocatable and buryable) and I want it to persist until the user
  explicitly kills it, and I want more than one instance of this type of
  window to be able to coexist on the screen (i.e. I want the user to be
  able to look at more than one object simultaneously).  I also want to
  be able to display mouse-sensitive presentations in these new windows.

(When you say 'window' I assume you mean 'frame.'  In clim, the visible
windows are the frame's panes, and those things can't be overlapped or buried
independently of the frame to which they belong.)

  Mechanically, I can do all of this.  My question is whether it makes
  sense from a consistent user inteface point of view, and, if it
  doesn't, how people suggest dealing with this user interface task in
  some other way.

It sounds like you are trying to implement the "desktop" metaphor.
This makes a great deal of sense but it may be difficult for clim
to deal with.

I have tried implementing it as having a bunch
of application frames that the user is free to bury, resize, reposition,
and so on.  The frames are conceptually part of a single activity, and this
causes some difficulty because it is not clear how they should all
interact.

What a desktop metaphor needs is a single top-level loop for reading
commands from any of several frames in the desktop.  It is possible
to trick clim into doing this, but it is a bit of a kludge and
requires getting your hands dirty with clim internals.
Even so, clim's design makes this alternative difficult because
you can't use *application-frame* anymore and because you have
to keep track of all the frames on your desktop so that things like EXIT
will do the right thing.  You also must redisplay frame panes
manually since clim doesn`t know how.

It is a little easier to associate each frame with its own process.
Then clim works pretty good, but only because you have
broken a single activity into artificially many activities.  The
worst part about this alternative is that you have many input contexts,
one for each frame, whereas there ought to be only one.

The impression one gets from reading the clim documentation is that
there must be a one-to-one correspondence between applications and
frames.  If you can live with this assumption, then your life will
be easier.  But I wish the assumption could be removed.
Follow-Ups: References:
Main Index | Thread Index