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

Re: proposals for meta-applications, frameworks, windows


These ideas are interesting.  Let me amplify a few points that
seem important.

1.  This concept of an "activity" serves to separate the top-level
loop (which provides the input context) from the frames (which
provide the screen real-estate).  In my mind, this separation
is the key element of this "desktop" metaphor that we are discussing.

2.  The activity must know what frames it manages, and be capable
of performing some window-manager types of operations on them.
I don't advocate applications that try too hard to override the
native window-manager; but I have found that operations such as
iconify/deiconify and stack-on-top/bottom are occasionally appropriate.
Also, when the EXIT command is executed, its frames must of course
go away.  One would also need a form of start-frame that was something
like the start-slave-frame that I previously posted, except that it
also pushes the frame onto one of the state variables of the activity.

3.  The top-level loop must do redisplay.  Something like
REDISPLAY-ACTIVITY-PANES would do just fine if it just called
REDISPLAY-FRAME-PANES on all of the associated frames.

4.  The activity must have methods to choose *standard-input*,
*standard-output*, and so on.  This is indeed tricky for the
reason that the top-level loop is now decoupled from the frames.
If we associate *standard-input* with some frame pane, and the
user makes that frame go away, what should happen?

One possible solution is to give one of the frames special
status, and to use that frame for *standard-input* and *standard-output*.
If it goes away, then the whole activity goes away.
The xman application has this feature.  This solution would
enable an "activity" to be implemented as a subclass of
application-frame.

jeff morrill
Follow-Ups: References:
Main Index | Thread Index