[mcclim-devel] Gadget based accepting-values

[Clinton Ebadi]

Troels Henriksen <athas at sigkill.dk> writes:

> 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.

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.

-- 
Jessie: but today i was a nerd
Jessie: i even read slashdot.