[mcclim-devel] Gadget based accepting-values

[Troels Henriksen]

Clinton Ebadi <clinton at 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.

-- 
\  Troels
/\ Henriksen