CLIM mail archive
RE: "Roll-your-own" Pane Types
Date: Thu, 14 Feb 1991 21:09 EST
From: will taylor <firstname.lastname@example.org>
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 <email@example.com>
In Symbolics CLIM 1.0, I would like to create pane instances of
((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"))
(: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
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))
(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.
(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)
-> :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))
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.
Main Index |