CLIM mail archive
[Prev][Next][Index][Thread]
Re: Overlapping windows to CLIM application frameworks
Date: Tue, 14 Jul 1992 14:46+0200
From: Stefan Bernemann <berni@iml.fhg.de>
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")?
CLIM 2 probably won't do any better than CLIM 1 on this point.
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
mind...
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?
Here is some code to get you started that should work in clim 1.1. The basic
idea is that you have one frame, called the "master", that works like
normal clim application frames and that is used to provide the top-level
loop for the whole "desktop."
All of the rest of the frames have no top-level loop, they merely
provide some real estate that you can draw upon. I call these the
"slave" frames. If they share the same input buffer as the master,
then presentations drawn on slave frames become "applicable" to the
input context provided by the master. (I don't know if this behavior
is a documented feature of clim, but I have found it to be true.)
(defun start-slave-frame
(frame &optional (master *application-frame*))
(let ((b (clim:stream-input-buffer (clim:frame-top-level-window master)))
(top-level-window (clim:frame-top-level-window frame)))
(labels ((set-input-buffer (window buffer)
(setf (clim:stream-input-buffer window) buffer)
(dolist (w (clim:window-children window))
(set-input-buffer w buffer))))
(set-input-buffer top-level-window b)
(clim:window-expose top-level-window)
(clim:redisplay-frame-panes frame :force-p t))))
References:
Main Index |
Thread Index