[mcclim-devel] Gadget based accepting-values

[Clinton Ebadi]

Troels Henriksen <athas at sigkill.dk> writes:

> Clinton Ebadi <clinton at unknownlamer.org> writes:
>
>> 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).
>
> Oh, so you don't see any problem with letting such initargs be up to
> the specific gadget view? That would also have another benefit, namely
> the ability of the view to easily filter the permitted initargs. It is
> possible that not all features of a gadget may be permitted when it is
> used in a dialog.

The Franz userguide (p. 148) says that gadget views are intended to
take all of the options of the related gadget. It doesn't make much
sense to allow initargs related to setting the value through though,
but is harmless (at least for the predefined views) since it would be
overridden anyway.

The only problem then is how to implement it. If the view has slots
for each option it is a bit of a pain to assemble the initarg list for
the gadget. With my quick implementation subclasses could specialize
view-gadget-initargs to remove any unsupported options.

>> 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.
>
> It should still be defined for each specific stream class, not in a
> superclass, since each specific stream implementation may want to
> implement it in a different way. FWIW, the
> standard-extended-output-stream implements it as just a slot with an
> accessor.

Ah ok. I didn't notice that there was a slot for it in
standard-extended-output-stream (I just saw the method on
accepting-values-stream and figured there was no slot for it).

>> I'll implement text-field based text fields in the next revision of
>> avg.lisp rather than falling back to textual-dialog-view.
>
> Do you think this should be the default? Do you think it should even
> be possible to use input-editing streams in dialogs?

For textually oriented dialogs using an input editing stream seems to
make sense. Are there streams in CLIM that cannot have gadgets on
them?

For gadget based views using text-field/text-editor is the saner
choice and I'm implementing that now (trying to figure out how to call
accept at the right time).

>> 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.
>
> It would be good if you could put it on http://mcclim.cliki.net, so
> that others can see what is missing (and possibly pitch in).

Will do.

>> 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.
>
> Most of the dialog gadget-views in the current implementation seem to
> inherit from gadget-view, not gadget-dialog-view, though. Should this
> thus be fixed?

I am fairly certain that the individual gadget views are supposed to
inherit from gadget-view; gadget-dialog-view is like
textual-dialog-view in that it represents the view for the entire
dialog. Perhaps someone has access to Allegro or LispWorks CLIM and
could check the class heirarchy? I can see why they might be derived
from gadget-dialog-view instead

>> 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.
>
> They aren't in McCLIM itself yet, partly because no-one is sure that
> everything is in place to support them. I have an example, though,
> that does work for my test cases:
>
 ...
>
> You will notice that:
>
> 1) It is a bit horrible.
>
> 2) It isn't really possible to automatically embed this in a dialog,
> the way we can currently do with input-editing streams. Perhaps it
> will always be necessary to have a specialised protocol for
> dialog-gadget-views (perhaps that is even the purpose of that
> class?). In that case, I think we should simplify your protocol and
> export it from CLIM-EXTENSIONS - or even better, find some existing
> CLIM facility that enables this.

The Franz userguide says that accept on a gadget-view outside of a
dialog is not intended to work. This makes sense to me because of the
mismatch between synchronous accept and asychronous gadgets; inside of
a dialog the entire dialog blocks allowing the desired behavior to be
achieved.

In any case you can always call accepting-values with just a single
accept and then it handles blocking until :exit is clicked
generically.

The big issue I see is that accept-present-default is called with the
encapsulated stream of accepting-values-stream rather than the
a-v-stream itself. This prevents user defined gadgets views from
working without accessing some internals (the
*accepting-values-stream*) or using a manual :value-changed-callback
and nastiness of throwing presentations around (and still then using
the internal com-change-query).

Is there any reason for this other than using input editing streams? I
tried a quick experiment with just passing the a-v-stream but it
failed in a few places. I got it to at least get as far as displaying
when I merged the a-v-record and a-v-stream types, but it blew up
after displaying the first prompt. The spec makes it seem that an
encapsulating stream should be transparant to most code (lack of
knowledge of CLIM here...).

If the accepting-values-stream itself were passed to
accept-present-default then creating a new gadget based accept would
be much cleaner:

(let ((top-level-stream stream))
  (updating-output (...) 
    (with-output-as-gadget (...)
      (make-pane ...
        :client top-level-stream
         ...))))

With all of the arcane magic hidden in the value-changed-callback
specialized on accepting-values-stream. There would still be some
uncleanliness owing to the lack of specification about how this should
work, but it's better than not being able to do it at all without
relying on internal methods. OTOH I don't know if this would be
portable anyway (still, using specified bits of CLIM is always nicer).

I'll work on simplifying the internal protocol now. button-labels
could just be done as a function typecased on (check-box radio-box) /
(option-pane list-pane) as it is really just a convenience function
for generating them.

encode/decode-gadget-view are also only really used for check/radio
boxes because they receive/return toggle-buttons instead of the values
contained within. This could be fixed by subclassing them and adding
:around methods to the needed methods to do conversion
automatically. Likewise for sliders and coercing the result from a
rational into a float or integer when needed. Does this sound like a
good idea?

I'm not quite sure how to eliminate gadget-initargs-for-view,
view-gadget-initargs, or make-gadget-for-view without creating a lot
of duplicated code. If the a-v-stream stuff can be resolved so that
users could create custom gadget views then the same things can be
accomplished by hand for the user views anyway. They also seem like
reasonable things to put into clim-extensions.

I've seen list posts mentioning CLIM 2.5 before. Which implementation
does this correspond to? If there is a manual for it online perhaps it
has more to say about this.

-- 
<captain_krunk> ntk is currently using "telnet fyodor 25" to send email