Clinton Ebadi clinton@unknownlamer.org writes:
Greetings,
Sorry for the late reply, I didn't have the time to properly check your patch until just now.
Attached is a patch, accepting-values-gadgets-1, that makes accepting-values capable of working of with gadget based views. The (probably) uncontroversal part is exporting the CLIM 2.2 (from the Franz user guide) gadget views and the related constants.
This patch is great! I've wanted this functionality in McCLIM for quite a while and it's great fun to play with.
I added view-gadget-initargs support to gadget-view so gadgets can be created properly. The code merely stashes all the provided initargs into a slot and does no sanity checking. Should this somehow verify that the initargs are valid for the related gadget class? If so, what would be the cleanest way?
Is this slot used anywhere in your code? I cannot find any uses, and I'd cautiously prefer letting specific gadget-view subclasses define initargs as appropriate for the gadget they support.
To the frame-manager protocol class I added the CLIM 2.2 frame-manager-dialog-view method which (for now) defaults to a textual rather than gadget based view. I noticed the XXX comment attached so I am unsure if this is an OK place to add it.
This looks like the right thing. Implementing CLIM 2.2 functionality is always a good thing, and there's nothing we can do about putting slot definitions in protocol-classes.lisp at the moment.
accepting-values-stream now returns the frame manager dialog view as its stream-default-view. The Franz user guide says that this ought to be setfable; to which class should I add the slot and accessor?
Probably to the accepting-values-stream itself.
To accepting-values itself I moved the final cleanup of the input editor records into a generic, finally-finalize-query-record, so that accept-present-default methods that don't contain a text editing field can actually work.
This is necessary, yes. Accepting-values is a bit of a hack, because I don't think CLIM actually specifies enough behaviour for it to be user-extensible...
This issue might also stem from the fact that McCLIM uses an input-editing-stream to implement the "default" dialog input fields. I've been told that classic CLIM uses text-field gadgets, which may arguably be a better solution in general.
There are a few quick hackish methods for accepting from a text-field-view/gadget-dialog-view (the assumption being that they contain an input editing record so just calling them with +textual-dialog-view+ will work). I also reworked the accept-present-default for text-field-view to always call the textual-dialog-view method even if the width is not set.
I don't fully understand what's going on here... which purpose does the gadget-dialog-view class serve? What kind of view is it?
Generally your patch seems to do the right thing. I'm not knowledgeable enough about CLIM dialog issues to fully judge its merits, but it looks good to me.
Also attached is avg.lisp which is a work in progress I'd like someone a bit more knowledgeable about CLIM to look at which implements gadget based accepting-values methods as per the Franz user guide. This is loosely based upon the public domain code found in [1]. If it looks ok I can split it up into the appropriate files in McCLIM and submit a patch. It seems to work well enough, but I am unsure if I have implemented things well. The most suspect bit is line 225 where I set the cache-test of the updating-output-record to return t always. I was having problems with a new gadget being created every time the value changed.
There is one thing here I take issue with, though it may mostly reveal my inexperience with dialogs: you create a bunch of new, internal presentation generic functions. This makes it essentially impossible for user-defined gadgets to be used in views. Wouldn't it be better to use the normal accept-by-gadget-view methods in dialogs (I know they don't fully work yet, yes)? I'm not much in favor of devising new, internal protocols until we are completely sure that the existing CLIM facilities are insufficient.
gui.lisp contains a small test frame for testing whether the gadgets actually work.
This program, and gadget views, do show some powerful CLIM qualities. I love how easy (relatively speaking...) it is to take gadgets out of their normal environment and stuff them into a command prompt setting.