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

frames and panes (East coast) versus overlapping independent windows (West coast)

    Date: Thu, 17 Dec 1992 10:20 EST
    From: "Donald H. Mitchell" <dmitchell@trc.amoco.com>

    I think I know the answer to this question, but you know what
    they say about people who assume they know the answer to
    everything :-)

    With all those MacHeads and UnixGoons out there using CLIM, you'd
    think that if it were easy to make CLIM handle West Coast windows
    there'd be contributions in Cambridge and discussions in the CLIM
    list.  But, alas, I see none (although I vaguely remember but
    cannot find a short discussion on this).  I assume that the lack
    of discussion is not because West Coast windows are obvious
    (and thereby left up to the reader).  But, is it so?

    We're moving a system from a controlled user population
    to the population at large and the population at large does not
    take to fixed layouts, paned frames, and other non-standard
    constraints. (Although they seem to relish the non-standard
    presentation system!)  I'm afraid we may have to use MCL's and
    Allegro PC's interface stuff with the concomitant lack of
    portability and CLIM functionality :-(

    I understand the CLIM developer's capital constraints and
    ontogeny; any (private) suggestions about what it would take ($$,
    time) to support something more Macish and MS Windowish?  Any
    other developers who would like to band together to weigh the
    business advantage of supporting such a development?

CLIM 2.0 has both a ``bboard pane'' whose children are a bunch of
unconstrained, possible overlapping windows.  There is also the notion
of a ``meta-frame'' in CLIM 2.0, which is an object that manages a whole
bunch of related, subsidiary frames that share a single input buffer.

Also, in both CLIM 1.1 and CLIM 2.0 you can create new windows (using
OPEN-WINDOW-STREAM) that share an input buffer with the owning frame.

All of these things combine to give you a pretty broad set of primitives
for doing what you want.

Are you suggestion a variant of DEFINE-APPLICATION-FRAME that somehow
does this as well?  Since we haven't expended any brain power on this
yet, concrete proposals would be appreciated (by concrete I mean that I
want a bunch of examples of code that use your proposed facility).


0,,
References:
Main Index | Thread Index