CLIM mail archive
Re: Overlapping windows to CLIM application frameworks
Date: Tue, 14 Jul 1992 08:46 EDT
From: Stefan Bernemann <firstname.lastname@example.org>
Date: Mon, 13 Jul 1992 19:39 MEST
From: Jeff Morrill <jmorrill%BBN.COM@fhg.de>
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
That's exactly what we need, too. Can someone comment on how CLIM 2.0
will deal with this subject? Are those "frame-managers" the solution
that clim programmers are to use/implement (without "multi-proceccing")?
No deep thought has been spent in this area. Nobody with a vested
interest has submitted any proposal in this area, never mind a coherent
proposal. As usual, concrete proposals are welcome.
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.
Can you provide some (example) code, as the documentation on how to
implement my own top-level loop seems to be too straight for my simple
The lisp listener from the examples also doesn't enlighten me too much
for this problem.
Again, is there a chance that the functionality of this code will be
part of clim 2.0?
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.
Thanks a lot - Stefan B.
Mail: Stefan Bernemann ! Phone: +49-231-9743-139
c/o FhG IML Dortmund ! Fax: +49-231-9743-234
Emil-Figge-Str. 75 ! Email: email@example.com
D-4600 Dortmund 50, FRG !
Main Index |