CLIM mail archive
Re: Overlapping windows to CLIM application frameworks
Date: Mon, 13 Jul 92 10:10:02 CDT
MMDF-Warning: Parse error in original version of preceding line at 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
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.
Main Index |