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

proposals for meta-applications, frameworks, windows

    Date: Wed, 15 Jul 1992 19:24 MEST
    From: Scott McKay <SWM%stony-brook.scrc.symbolics.com@fhg.de>

	Date: Wed, 15 Jul 1992 09:22 EDT
	From: Vincent Keunen <nrb!keunen@relay.eu.net>

	    Date: Tue, 14 Jul 1992 17:17+0200
	    From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>

	    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.

	I haven't though deeply either, however, I think CLIM has a concept of
	applications (at least a word for the concept, cf
	define-APPLICATION-framework...).

	I think it's adequate. But...

    This following two paragraphs will sound a bit like I am scolding Mr.
    Keunen, but that's really not my intention.  But this message is a good
    example of useful information that is not actually a concrete proposal.

    The reason I asked for a concrete proposal is that I myself have not
    ever had the need to use multiple application frames that interconnect
    beyond simply sharing data through an agreed-upon "database" of some
    sort.  Therefore, I am not sure I can design a module that adequately
    serves the needs of people who do need such a thing.  Therefore, I need
    one or more concrete proposals that describe exactly what people want to
    do.  The more specific, the better; so a proposal complete with classes,
    generic functions, and examples of use is most desirable.

    So, while this input is useful, this is not what I mean by a "proposal".
    At the very least, a concrete proposal should outline precisely what is
    being accomplished, and documents a set of classes and generic functions
    on those classes.  

    ...

This won't be a concrete proposal either, I try to describe what's
needed from our perspective. (The use of "we" in this message denotes
people of our institute) 

Much of our background and experience with the use of window-based user
interfaces was formed by the macintosh. Applications on the
Macintosh are using the "document methaphor". That is, an application
works on one or more "documents", an open document is associated with a
window on the macintosh desktop. In terms of clim, such a "document
window" would be an instance of an application frame. These
document-windows can be freely moved on the macintosh-desktop, i.e. they
are under the control of the server's window manager. 

As far as my limited experience with (MS)windows on a PC goes, things
are different in that an application (e.g. an editor) is associated with
an "host window" (forgive me the unprecise terms) and *inside* this
window different document-windows can be created. This is, what could be
done with clim by creating an application-frame-object with another one
as its parent -- as far as I understand the documentation. However, this
seems to confuse the window-managers at least on my mac (using clim1.0b
with mcl 2.0bp3) and under genera (8.1 with clim1.0). BUT -- I don't
want that behavior, at least as long as I'm not porting the application
to PC-platforms. 

Under motif, there are as well applications with serveral "independant"
windows, cf xman as an simple example.

Summarizing, it should be possible to let an application consist of
serveral (not neccessariliy limited at compile time) windows. These
windows may have "equal" structure (like document-windows on the
macintosh), but this need not to be.

After this long prologue, where does this not fit into the clim model?
I would use application frames to implement these different windows. But
then there's no concept to say "these instances of application frame objects
belong to or form one 'application'". Let me name this concept
"activity". An activity is informed about what application frame objects
are created, it manages some sort of communication between them. This
can be implemented on top of clim, no problem. 

But, the top-level loop should be associated with an activity, not with
individual frames. Having multiple processes and doing some careful
synchronization, one can *emulate* this behavior, however this fails on
platforms not supporting processes and, what is more, I feel it is
conceptually better to have one top-level associated with an activity.
(Like one top-level now "controls" serveral panes -- from this point of
view, the document windows are somewhat like freely moveble panes).

To implement this, (at least) two things are needed: 
First, a closer interaction with the window-magager of the display
server. The activity (or the involved application frame object) must
become informed when a user selects / activates / deactivates a
(top-level) host window. In other words, instead of the special variable
*application-frame* the should be something like *activiy* AND the
activty must know about the "selected" or "active" application-frame.
Different window systems have different meanings of windows being
"active" or "selected", so that's not so trivial. But that's basically
what I mean by "closer interaction". As far as I understand the 2.0
specs, the frame-managers try to adress this problem? The current
solution, just binding the variable in the top-level-loop (having a
per-process-binding) does not reflect "what's going on on the user's
screen".

Second, the top-level-loop must be more carefully designed where to get
input from and where to do output. I think, it's ok to share one
input-buffer among all frames of the activity. That's what clim now does
do serve different panes and this can be done now already to implement
one top-level-loop serving serveral frames (using only advertised clim
functions!). However, the programmer must specify, where to do output,
where to echo commands etc. Exampele: A (end-)user has entered a partial
command in one frame (window), then he switches to another frame. In
that case, he can of course only enter the arguments to the partial
command, not a new command -- otherwise there would be a principally
asychronus behavior, use processes if you need this. But, if the second
frame has a pointer-documentation pane, the command loop should redirect
the documentation to this pane, as this frame is now the user's focus.
how command echoing should be done is event more application dependant,
so these aspects must be specified by the programmer.

I don't know if these statements are helpful, I could spend some more
thoughts about it during the weekend. This mail seems to be long enough
for now, so nice weekend to everybody - 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:  berni@iml.fhg.de
      D-4600 Dortmund 50, FRG !
Follow-Ups: References:
Main Index | Thread Index