Troels Henriksen athas@sigkill.dk writes:
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.
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:
It is a bit horrible.
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.