🚀 go-pugleaf

linton@marktwain.rad.sgi.com (Mark Linton) writes:
>In article <Bwn7CG.4oL@cpsc.ucalgary.ca>, roseman@cpsc.ucalgary.ca (Mark Roseman) writes:
...
>|> 2. Library structure
>|> --------------------
>|> While I can appreciate the rationale for eliminating many of the intermediate
>|> classes and using kits to instantiate objects from more basic classes (see
>|> Mark Linton's "Encapsulating a C++ library"), unfortunately it is making
>|> InterViews ridiculously difficult to extend, or to reuse existing code.
>|> 
>|> Creating a new WidgetKit subclass to customize a particular widget is too
>|> heavy-weight an operation.  Without intermediate classes (e.g. a PushButton
>|> rather than just a Button) subclassing is almost impossible.  The main
>|> advantage I saw to the kits was to provide a central place to look for 
>|> widgets rather than searching through tons of include files.

> Please explain why you want to subclass a PushButton.  I understand
> the need to subclass Glyph, MonoGlyph, or InputHandler; both those are supported.
> Push buttons are better used through instancing.  If you want a glyph
> with similar functionality to a push button, define a monoglyph with the
> extended functionality and put a push button inside it.

Pardon me for intruding with my own dim memory of why I wanted to mess around
with PushButton.  I wanted buttons for which the ornamentation would "show"
only when they were active, and otherwise only the label would be visible.
For a fake 3-D look, that means three graphic states, in/out/flush, and a
set of new considerations about responding to pointer events.  I wouldn't
at this time bet my life that there isn't a way to do it without subclassing
PushButton (or hijacking the source), but just right off hand it seems like
a more likely approach than instancing as described above.

I think I understand some of the benefits of encapsulation, but I read the
above-mentioned article with a rather ironic appreciation, as I was just then
struggling with the features touted therein.  I think that for a toolkit to
have much growth potential, its implementor needs to leave some margin for
development past what he or she can personally envision, which is obviously
kind of tricky.

	Donn Cave, University Computing Services, University of Washington
	donn@cac.washington.edu