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.