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

Re: proposals for meta-applications, frameworks, windows

This is off the top of my head, so don't hold me to it being a complete,
formal proposal - it ain't.

There are two different situations: one is that you want to have most of a
CLIM applications real-estate power in more than one frame; the other is where
you want to have semi-independent applications using all of CLIM's power but
able to be controllable at the window manager level.

Let me give examples of each:

Real-estate in more than one frame - I have an application that needs lots of
different layouts, sometimes I'd like to have more than one of those layouts
on the screen at the same time, and every possible set of up to (say) three is
possibly desireable.

Semi-independent applications - I have an application that allows someone to
browse a database and to modify it. Examining, adding, or changing particular
pieces of information in that database, I'd spawn seperate examiner/editor
applications - when they're done they return.

I guess the big difference to me is whether or not the family of applications
shares a command table and a process. In my first example, they would. In my
second, they wouldn't.

However, there's also the matter of controlling a family of applications as a
unit. Within the context of the window system, these windows are a loosely
coupled unit. If I kill one I should probably find myself looking at a sib or
parent. If I kill a parent, its children should die (or I shouldn't be allowed
to kill it without being notified of its children's imminent death). If a
frame is temporary it should get killed off when clicked off of (same as a
menu).

Finally, a mechanism for defining a frame family, so that you could define
frame-family commands, which all members of the frame family could access.

(define-frame-family ((frame-type-list list-of-application-frame-types)))

(make-annotation-frame ... :family (:parent *application-frame*) 
                       (:temporary nil) ...) 

OR

(make-annotation-frame ... :family (:sibling *application-frame*) ...)

;; Functions for getting at other members of the application-frame's family.
(frame-children (frame application-frame))                  <= method
	returns list of frames

(frame-descendents (frame applcation-frame))                <= method
	returns list of trees of frames (i.e. there's an entry for each child,
	but the entry is a list reflecting the structure of descendents).

(parent (frame application-frame))                          <= method
	returns a frame

(frame-siblings (frame application-frame))                  <= method
	returns a list of frames

(frame-family (frame application-frame))                    <= method
	returns a tree with the root being the CLOS-object representing the
	family, and then the frames organized heirarchically.


modify frame-exit to take a (:switch-to frame) argument with default being the
parent (if there is one) or a sib (otherwise).
References:
Main Index | Thread Index