PortaCello3 Update [was Re: [cello-devel] scroller]

[Kenny Tilton]

Thomas F. Burdick wrote:

>Kenny Tilton writes:
> > 
> > I would use multiple inheritance and avoid the complexification of 
> > adding a whole new mechanism. The Cello GUI hierarchy, for example, has 
> > radio-button-ness as a mixin, so it can be a check box, bullet, or even 
> > a pushbutton (that stays in while selected, like a real car radio button 
> > back in the day.) Of course Garnet is not CLOS, so interactors are 
> > probably a very nice substitute.
>
>This is really a textbook example of where MI is useful, huh.
>

Yep. I know MI is controversial, but when you get to a case like this 
and with a little refactoring one can take the scroll-stepper and carve 
out a reuseable (via MI) ct-semi-automatic that can be mixed-in with any 
otherwise single-action widget just by sticking it in the superclass 
list, I really shake my head at the controversy. Never mind venerables 
such as Gabriel and Graham who cannot tolerate OO at all.

Meanwhile I am LMAO because I just realized that as an experiment in OO 
in response to your laughing at the idea of a class being defined just 
to bundle up a popular set of initargs, I created scroll-stepper arrow 
widgets in a function which supplied all the customization. Can't add 
that to the superclass list. Of course I could dig myself deeper (I 
actually did something like this in CliniSys) and have a GF cook up the 
initargs, then make the method combo such that the args get collected 
such that the rule (first arg in where args are repeated? I always 
forget) DWIM, but .... nah.

Anyway, I am now slogging through Frank's code and mine carving out 
hard-coded fonts and pathnames into a configure.lisp, then I will have 
to get the whole mess working again including via ASDF. Shouldn't take long.

btw, thanks to Frank for taking so much trouble to do a structured fix 
when incompatibilities came up. I can see a lot of work went into that.

btw2, a note to everyone, not just Frank, in re changing the variable 
names from, say, *glut-dll-path* to *freeglut-dll-path*. Well, I /think/ 
i know what is going on there (more precise naming?), but maybe I am 
wrong. So I will just say that Cello is going to follow the FreeGlut 
model of staying binary compatible with the Glut specification, so that 
we can swap in at build time any of Freeglut, Glut classic, an OS 
vendor's Glut, or even the upstart OpenGlut project. This because, as 
Thomas suggested a ways back, vendors such as Apple sometimes do groovy 
things with the Glut, so we might pick up some nice energy that way, 
making up to some degree for having to deal with callbacks from C.

In fact early on I did variously load the standard glut vs freeglut to 
check my sanity on things. I won't bother flipping those names back 
until I am sure what is going on there, but I thought I would at least 
make clear the standing Freeglut has in Cello: just one of many 
interchangeable Glut implementations.

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application