Troels Henriksen athas@sigkill.dk writes:
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.
Yes, it is used in make-gadget-for-view to pass any user specified initargs to the gadget created for the view. This was just a quick make-it-work thing. I think LispWorks CLIM has a similar method (at least a comment in the original pavp.lisp made it seem so; I have no idea since I have no access to any proprietary implementations).
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.
On page 149 of the Franz user guide it seems to say that stream-default-view should be setfable on every stream, and that on accepting-values streams it should be frame-manager-dialog-view by default.
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.
I'll implement text-field based text fields in the next revision of avg.lisp rather than falling back to textual-dialog-view.
I've also been building a planner page with a list of the unimplemented features of accepting-values and I intend to implement the ones that I can. I have :exit-boxes implemented and a first stab at accept-value-command-button.
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?
The gadget-dialog-view class is the default for gadget based dialog streams, and resolves to sane default views for basic types. See page 150 of the Franz UG.
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.
Could you point me toward these accept-by-gadget-view methods? I couldn't find anything with a similar name in the clim-internals package or the spec or the franz user guide; I'm fairly new to CLIM (I wrote this so I could use presentations and still have option-panes and such in my first CLIM program) so I'm not sure where everything is yet.
I'm not sure if the CLIM spec specifies enough for a user to add his own gadget views except when built upon the ones provided by the implementation. It would be nice if there were though, or, failing that, compatibility with other CLIM implementation's internal protocols for this. As McCLIM is the only CLIM I have access to I require some guidance here.