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

Application frames, windows, panes...

    Date: Thu, 24 Oct 1991 10:09 EDT
    From: "John G. Aspinall" <JGA@alderaan.scrc.symbolics.com>

	Date: Thu, 24 Oct 1991 06:57 EDT
	From: keunen@milou.nrb.be

	...

	But working on a mac makes things different.  Considering the usual way the mac 
	interfaces with the user (multiple windows, containg areas that might be called 
	panes), I'm wondering what's the best way to design code for that using clim 
	concepts.

	First, I don't really see where clim "windows" and "streams" fit in the 
	application frame/panes architecture.

    Let's leave streams out of it.  Streams are things that obey one of the
    stream protocols (input or output, basic or extended).  Windows can be
    streams, but so can internal buffering mechanisms, file-streams,
    hardcopy-streams etc.

That is, a stream is a handle to some input and/or output "device" that
supports the stream protocols.

    Windows are (informally) things that occupy screen real-estate.  Now,
    since CLIM is NOT a window system, there is another entity - the
    underlying window system, and in particular the window manager for that
    window system - that also has its hands on the same (conceptual)
    windows.

    Most window systems support individual windows, and also support
    subdivided windows.  The windows which comprise the pieces of a
    subdivided window are called panes, in CLIM language.  But there's
    another concept we have to deal with.  That is "all the windows
    belonging to an application".  Those windows, as you point out, may or
    may not be *geometrically* associated.  If they aren't tied together by
    geometric constraints, then a window manager might as well treat then as
    independent.  Except for one thing - selection or input focus behaviour.
    When you select any one of those windows, you *probably* want things to
    happen to all the windows associated with that application together.
    This is an area where CLIM and the window manager have joint
    responsibility.  (In old Symbolics paralance, this is an "activity",
    often discussed but never fully implemented.)

    The current CLIM is lacking a complete solution to this problem.
    Instead, we have frames which are both a single window (possibly divided
    into panes) and the root of "all the windows belonging to the
    application".  Eventually, these two concepts will separate.

So, a "frame" is a special object that stores a bunch of state for a
particular application, including a "top level window".  A "pane" is a
window that is the child of the frame's top level window.

				      Looking at the mac interface, it seems 
	like one could say "there is an application, with several windows (at the same 
	time and somewhat independent - but not always) and panes within these windows.

	How would that be (nicely) coded in clim?

    As you have now gathered, we're still figuring that one out.

0,,
References:
Main Index | Thread Index