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

proposals for meta-applications, frameworks, windows...(long message)

    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.  

    1- proposal for a meta-application
    ----------------------------------
    For multiple instanciations of applications (select-c-?), there should
    be a "higher thing" if there is a need to control all the applications.
    I can imagine several applications using common information - something
    like a central database.  The specific application information can be
    stored in state variables (things like "preferred view" for visual
    representations,...) and that's good.  But for the moment, the only way
    to share between applications is by using global variables, which is too
    "high level", I think.

Global variables are simply a special case of an agreed upon "database".
There are more flexible ways to do this, but global variables are not
inherently bad for this purpose.

    The "higher thing" could be named something like a meta-application, or
    an application-manager,...

    It should have state variables of its own and, at least, a list of
    applications that it "manages".

I believe that a normal CLIM application frame can serve exactly the
function of what you call a "meta-application".

    2- proposal for DAs
    -------------------

    CLIM also has concepts of frameworks, panes and windows.  I must
    admit that I've long been mixed up with these and I'm not sure I can put
    all the pieces in the correct places yet.

    First it seems to me that clim-windows are not the same as
    things-usually-called-windows (in X, Mac, ...).  If I am correct, these
    systems all talk about a root window (one per screen??) that has
    child windows (for the mac, the root window could be the desktop).

A window in CLIM is the same as a window in X or MCL or whatever.  A
pane is a window whose parent is an application frame.  An application
frame is an object that groups together some state variables,
(optionally) a process, a command loop, and zero or more panes.

    I think that the questions of applications and visible objects have to be
    separated.

    So what we need could be (this is my first try):

I am not sure that the following addresses what people are asking for,
which I understand to be a principled way for one single "meta-application"
to control a number of inferior applications.

I certainly don't think that CLIM 2.0 should be breaking ground in the
area of "virtual distributed desktops".  Maybe later...

    Preliminary:
    Since everybody uses the same words in various senses, I'll try to use
    words that mean nothing (don't say I always do!).  This way, the
    confusion will be lessened and words will be found later for these
    entities.  I'll talk about DAs (for display areas).  They need not be
    real DAs, they could be virtual and/or infinite (as with clim's drawing
    panes).

       a level0-DA: the ancestor of all level1 DAs (has pointers to them)
       a level1-DA: the most general area where display can occur (it can
	    be shared by various machines - useful for future very heavy
	    applications that use multiple machines to cooperate in the
	    display of something).  In the X world, all the
	    network-distributed windows could be part of the same level1-DA.
	    This could also be called something like "virtual distributed
	    desktop".

       a level2-DA: the total area a single machine can access
	    locally (the generalized desktop, maybe displayed on more than
	    one screen - cf a mac with several screens) 

       a level3-DA: this could correspond to the area displayed by a unique
	    screen on one single machine.  This is the first DA not to be
	    virtual (or could there be virtual screens?).
	
       a level4-DA: could be a single visible object (a window in most
	    window systems, but also a framework in clim's terms if my
	    understanding is correct).

       a level5-DA: a subdivision of level4-DA (panes for clim).

       etc...


    Now I'm asking the specialists: will there be a mapping from all other
    systems' concepts (X-root window, X-window, mac desktop, mac window,
    clim's frame, panes, views, viewports, menus, dialogs, sheets,...) to
    these????

    From there, one could see where the connection between applications
    (processes,...) and DA is best done.  Does an app manage leveli-DA?
    etc...

    These are my first thoughts...  Please comment on these.
Follow-Ups: References:
Main Index | Thread Index