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

RE: "Roll-your-own" Pane Types

    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.

    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.

    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.

   ....

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

    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.

==> Will Taylor

0,,
Follow-Ups: References:
Main Index | Thread Index