[mcclim-devel] Gadget based accepting-values

[Clinton Ebadi]

Greetings,

I ironed out a few bugs in my implementation some weeks ago and almost
have my gadget based dialog code working now, but my laptop decided to
mysteriously die (someone spilled a very sugary drink into my laptop
case and I put my laptop into the case...) so I've been unable to code
for a bit as my only other machine lacks a monitor at present. I
managed to fix my laptop yesterday (the Internet is a wonderful place
where one can find technician service manuals).

I intend to have the patch working with equivalent functionality to
the current accepting-values by the end of July. Right now I'm focused
on getting clisp and ffcall working on EABI ARM and packaged for
openembedded (mcclim on the neo freerunner!) and the intial work for
a startup I recently joined so it will be a week or two before I have
time to finish ironing out the last few issues.

My big question now is: is it ok if the gadget based accepting-values
is not user extensible? I fetched the CLIM mailing list archives and
it seems that the spec is indeed woefully underspecified in this area,
and so making accepting-values user extensible will require shaping up
the current implementation and exposing bits of the protocol as a
mcclim extension. I am willing to work on this later, but right now am
lacking the time to undertake such a large projet (the economy is
cruel and demands that I do things for it lest I starve). Perhaps in
September I'd be able to make things extensible, but I figure that a
nonextensible gadget based accepting-values is nicer than a
nonextensible text field based accepting-values.

-- 
         To set your mind free you must first just listen
     Don't waste your life on worthless hate and contradiction