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

RE: "Roll-your-own" Pane Types

    Date: Thu, 14 Feb 1991 21:09 EST
    From: will taylor <taylor@charon.arc.nasa.gov>

Just to finish this discussion...

	Date: Thu, 14 Feb 1991 11:41-0500
	From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>

	    Date: Wed, 13 Feb 1991 21:10 EST
	    From: will taylor <taylor@charon.arc.nasa.gov>

	    In Symbolics CLIM 1.0, I would like to create pane instances of

	...

	    (define-class COMMAND-PANE-CLASS
			      (clim::sheet-window-stream)
		 ((command-list 	:initform () :documentation "list of cmd-definition structures")
		  (enabled-style 	:initform '(:sans-serif :bold :large)
				    :documentation "enabled character style")
		  (disabled-style 	:initform '(:sans-serif :roman :normal)
				    :documentation "disabled character style"))
	      (:accessor-prefix cmd-pane-)
	      (:initargs :slot-names)
	      (:documentation "Command pane class for enabled/disabled command fonts"))

	...

	There is also a future portability problem here, namely, you are
	specializing CLIM::SHEET-WINDOW-STREAM, which is a Genera-only class.  

    I would like to be able to specialize on a portable CLIM stream class, in
    order to specialize methods and instance slots portably.

Right now you can't specialize stream classes *portably*, because in CLIM
Release 1.0 the stream classes that have instance instantiated are, by
definition, platform-specific classes, for example, SHEET-WINDOW-STREAM
or CLX-WINDOW.

	CLIM Release 1 has no provision for specializing window classes and
	having DEFINE-APPLICATION-FRAME create them.  All CLIM windows in CLIM
	Release 1 are the same class.  I believe that CLIM Release 2 addresses
	this sort of issue better.  Is it *really* important for CLIM Release 1
	support having DEFINE-APPLICATION-FRAME be able to create different
	classes of windows in its panes (see the end of the message for a
	strawman proposal)?  I mean **really** important?

    The two major user interfaces which I want to port to CLIM make extensive use
    of methods and instance slots specialized to my application panes.

I still think it is better to keep application state in a place besides
in a window class.  But it's up to you.

	Lacking any broader context, the example you supply does not offer a
	compelling reason for providing this capability, since the state you are
	storing in the "command pane" could just as easily be maintained in state
	slots in the application frame itself.  I suggest that, rather than
	digging into undocumented parts of CLIM, such as CLIM::PANE-TYPE-OPTIONS
	and CLIM::SHEET-WINDOW-STREAM (which being both undocumented and
	unexported are consequently subject to change without any notification),
	that you try to stay within CLIM's documented and exported features and
	maintain this state in the application frame.

    I would very much like to do that.  I believe that CLIM 0.9 (Franz) allowed
    user defined pane type classes, and I guess you are saying (above) that
    CLIM 2.0 will probably have this feature.  In the meantime (~ 6 months) I
    would like to get my user interfaces converted to CLIM 1.0.  To do that I
    apparently will have to modify my method handling from being specialized
    on user defined pane classes to not being specialized, e.g. from

	    (defmethod DISPLAY-COMMAND-PANE ((frame-object application-frame) (self COMMAND-PANE-CLASS))
	      ...)
    to

    (defmethod DISPLAY-COMMAND-PANE ((frame-object application-frame) self)
	      ...)

    And instance slots which would have been associated with COMMAND-PANE-CLASS
    will have to be added to the frame state variables.  It seems an awkward
    way to do it.

I've added :WINDOW-CLASS as one of the pane options to DEFINE-APPLICATION-FRAME,
so people can do with it what they will.  This may make it to the field
before as a patch to the early release of CLIM 1.0, but then again it may not. 

       ....

	----------------

	Here is how you would use the strawman I have in mind.  It still has the
	bugs of being non-portable, since you have to specialize CLIM::SHEET-WINDOW-STREAM.
	Also, as I said above, I think we need more compelling examples for why
	doing this is much more important than doing other things, since we do
	not have unlimited resources.


	  (defclass command-pane-class
		    (clim::sheet-window-stream)
	    ((command-list ...)
	     (enabled-style ...)
	     (disabled-style ...))
	    ...)
  
	  (defmethod display-command-pane ((frame application-frame) (pane command-pane-class))
	    ...)
  
	  (defmethod clim::pane-type-options ((type (eql ':autoclass-command-pane)))
	    '(:default-text-style (:sans-serif :bold :large)
	      :incremental-redisplay nil
	      :display-function display-command-pane
	      :display-after-commands nil
	      :scroll-bars nil
	->    :WINDOW-CLASS COMMAND-PANE-CLASS))
  
	  (define-application-frame autoclass-results-frame ()
	      ((global-pane :initform nil :accessor global-pane)
	       (global-header-pane :initform nil :accessor global-header-pane)
	       (banner-pane :initform nil :accessor banner-pane)
	       (command-pane :initform nil :accessor command-pane))
	    (:panes
	      (...
		(command :autoclass-command-pane)
		...))
	    ...)
  
    The "strawman" proposal looks good, assuming that a portable functionality
    will be available in CLIM 2.0.  It would allow me to eliminate awkward code 
    mashing and retain the object-oriented functionality of my user defined
    panes.  It would allow user extension of CLIM which would be portable,
    and object-orented -- which I thought was an important goal.

Implementing this strawman is utterly trivial, so I did it.  I don't
much like it, but you seem to think it will be useful.

0,,
References:
Main Index | Thread Index