[mcclim-devel] Gadget based accepting-values

[Troels Henriksen]

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.

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

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

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

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

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

(define-presentation-method accept ((type subset-completion)
				    stream
                                    (view list-pane-view)
				    &key)
  (with-look-and-feel-realization ((frame-manager *application-frame*) *application-frame*)
    (block body
      (multiple-value-bind (list-pane list-record)
          (with-output-as-gadget (stream)
            (make-pane 'list-pane :items sequence
                                  :mode :nonexclusive))
        (multiple-value-bind (button-pane button-record)
            (with-output-as-gadget (stream)
              (make-pane 'push-button
               :label "Done"
               :activate-callback #'(lambda (button)
                                      (declare (ignore button))
                                      (return-from body
                                        (gadget-value list-pane)))))
          (declare (ignore button-pane))
          (unwind-protect (loop (read-gesture :stream stream))
            (delete-output-record list-record (output-record-parent list-record))
            (delete-output-record button-record (output-record-parent
				    button-record))))))))

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.

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

I don't have access to anything but McCLIM either. I would not be
surprised to hear that commercial CLIM implementations do not have the
extensibility I would like to see in McCLIM. They often differ from
how I would imagine a good CLIM implementation to work. :-)

-- 
\  Troels
/\ Henriksen