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

"Roll-your-own" Pane Types

    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

It is preferable if we all get in the habit of callinf this "CLIM
Release 1.0", just so that we are all speaking the exact same language.

Also, please be specific about exactly what software you are running,
such as what operating system you are using (it looks like Genera here).
In order to diagnose anything, we really need complete information about
all of the software, not just which version of CLIM you are running.

    (pcl: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"))

Why PCL:define-class?  Why not [CLOS:]defclass?  If that is really
defining a PCL class, and since CLIM is written using "the real
[Symbolics implementation of] CLOS", there could be some coexistance
problems between CLOS and PCL.

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

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?

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.

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

    so I define it as a pane type --

    (defmethod CLIM::PANE-TYPE-OPTIONS ((type (eql 'COMMAND-PANE-CLASS)))
      '(:default-text-style (:sans-serif :bold :large)
	:incremental-redisplay nil
	:display-function display-command-pane
	:display-after-commands nil
	:scroll-bars nil))

    then --

    (define-application-frame AUTOCLASS-RESULTS-FRAME
			      ()		; No super classes
      ((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 command-pane-class)))
      ...)

BTW, if those slots in the application frame are meant to store pane
objects, why not just use the documented CLIM:GET-FRAME-PANE?

    but when I try to bring this up -->



1    Error: No applicable method for #<CLOS:STANDARD-GENERIC-FUNCTION DISPLAY-COMMAND-PANE 216445356> with arguments 
0	   1(#<AC-UI::AUTOCLASS-RESULTS-FRAME 46610725> #<CLIM::SHEET-WINDOW-STREAM /x 0:744 y 53:90/ 46615175>)

0    The following specials have been rebound; use 2:Show Standard Value Warnings0 for details:
      *PRINT-CIRCLE* and *PACKAGE*

1    CLIM::CALL-DISPLAY-FUNCTION
0       Arg 0 (CLIM::DISPLAY-FUNCTION): DISPLAY-COMMAND-PANE
       Arg 1 (CLIM::FRAME): #<AC-UI::AUTOCLASS-RESULTS-FRAME 46610725>
       Arg 2 (CLIM::PANE): #<CLIM::SHEET-WINDOW-STREAM /x 0:744 y 53:90/ 46615175>
       Rest arg (CLIM::ARGS): NIL

    because the (CLIM::PANE) is not my type: 'COMMAND-PANE-CLASS.  I want to
    do it this way to "attach" instance variables and methods to my pane types.
    Is there a different approach to doing this?

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

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)
	...))
    ...)
  

0,,
Follow-Ups: References:
Main Index | Thread Index