Clinton Ebadi clinton@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. :-)