Greetings,
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.
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?
I also caught the lack of a +check-box-view+ and added it.
To the frame-manager protocol class I added the CLIM 2.2 frame-manager-dialog-view method which (for now) defaults to a textual rather than gadget based view. I noticed the XXX comment attached so I am unsure if this is an OK place to add it.
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?
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.
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.
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.
gui.lisp contains a small test frame for testing whether the gadgets actually work.
[1] http://osdir.com/ml/lisp.mcclim.devel/2006-04/msg00069.html
Clinton Ebadi clinton@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.
To the frame-manager protocol class I added the CLIM 2.2 frame-manager-dialog-view method which (for now) defaults to a textual rather than gadget based view. I noticed the XXX comment attached so I am unsure if this is an OK place to add it.
This looks like the right thing. Implementing CLIM 2.2 functionality is always a good thing, and there's nothing we can do about putting slot definitions in protocol-classes.lisp at the moment.
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.
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.
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?
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.
gui.lisp contains a small test frame for testing whether the gadgets actually work.
This program, and gadget views, do show some powerful CLIM qualities. I love how easy (relatively speaking...) it is to take gadgets out of their normal environment and stuff them into a command prompt setting.
Troels Henriksen athas@sigkill.dk writes:
Clinton Ebadi clinton@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.
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. :-)
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.
Clinton Ebadi wrote:
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
In Lispworks CLIM, which seems to match the CLIM 2.2 spec (although you can't tell that from the documentation)
standard-object clim:view clim:textual-view clim:gadget-view clim:gadget-menu-view clim:gadget-dialog-view clim:internals::actual-gadget-view clim:check-box-view, etc clim:pointer-documentation-view clim:textual-dialog-view clim:textual-menu-view
Paul
Clinton Ebadi clinton@unknownlamer.org writes:
For textually oriented dialogs using an input editing stream seems to make sense. Are there streams in CLIM that cannot have gadgets on them?
None that can have input-editing streams on them, anyway.
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).
But what about the default view, when nothing else is specified? With the input-editing stream, you get completion, which is nice. Can this be replicated with gadgets, I wonder?
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
Oh yeah, it seems I was confused (who'd have thought?).
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.
The Franz documentation does indeed say that, but I have seen screenshots from other CLIM implementations where it is clearly supported. And as you can see from my example, it's possible to get it to work.
It's not a big issue to actually define a bunch of presentation methods for gadget views outside of dialogs, though, I'm willing to postpone that to a later date.
[technical issues]
I'm not familiar enough with dialogs to provide advice on this, so I'll defer to your recommendations.
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.
I have never heard of CLIM 2.5 before. I have, however, heard of CLIM 2.1, which seems to be LispWorks CLIM.
Troels Henriksen athas@sigkill.dk writes:
The Franz documentation does indeed say that, but I have seen screenshots from other CLIM implementations where it is clearly supported. And as you can see from my example, it's possible to get it to work.
It's not a big issue to actually define a bunch of presentation methods for gadget views outside of dialogs, though, I'm willing to postpone that to a later date.
I could see this working with an :around method on accept-present-default for normal gadget-view outside of a dialog. I may try to implement this later, but I do want to get back to the program I was writing first (my initial itch has nearly been scratched, but polishing little bits of mcclim is fun).
I've attached a new patch that sets up the framework for getting gadget based dialogs working, and also adds initial support for setting the :exit-boxes of an accepting-values stream. I also have a function for displaying them nicely on a gadget based stream (which I'll send in with the patch to add the rest of the gadget based dialog code):
(defmethod display-exit-boxes (frame stream (view gadget-dialog-view)) (updating-output (stream :unique-id 'buttons :cache-value t) (with-look-and-feel-realization ((frame-manager frame) frame) (fresh-line stream) (with-output-as-gadget (stream) (horizontally () (make-pane 'push-button :label (second (assoc :exit (exit-boxes *accepting-values-stream*))) :activate-callback (lambda (g) (declare (ignore g)) (com-query-exit))) (make-pane 'push-button :label (second (assoc :abort (exit-boxes *accepting-values-stream*))) :activate-callback (lambda (g) (declare (ignore g)) (com-query-abort))))) (terpri stream))))
I think the patch is good enough to merge into cvs. I'm finishing up the last few issues with the gadget dialog views now, and should have a set of fairly clean working patches in a few days.
Clinton Ebadi clinton@unknownlamer.org writes:
I've attached a new patch that sets up the framework for getting gadget based dialogs working, and also adds initial support for setting the :exit-boxes of an accepting-values stream. I also have a function for displaying them nicely on a gadget based stream (which I'll send in with the patch to add the rest of the gadget based dialog code):
Whoops, I accidentally reverted the finally-finalize-query-record bit. Attached is a fixed patch.
And of course I forgot to change gadget-dialog-view to gadget-view in the superclass list of text-editor-view too, but on second thought it's probably worthwhile to hold off committing my patch if anyone intended to until I finish a few more infrastructure updates. I realized why passing the accepting-values-stream directly to accept-present-default did not work: mcclim encapsulated streams don't implement the incremental redisplay protocol depsite being required to.
I'm fixing that and passing accepting-values-stream directly to accept-present-default. It is really required to allow library users to use gadget views for accepting anything other than primitive types.
Troels Henriksen athas@sigkill.dk writes:
It's not a big issue to actually define a bunch of presentation methods for gadget views outside of dialogs, though, I'm willing to postpone that to a later date.
[technical issues]
I'm not familiar enough with dialogs to provide advice on this, so I'll defer to your recommendations.
Ok, I have now attached a third revision of the patch to add the infrastructure needed to support gadget based accepting-values dialogs. The big change is that encapsulating streams now support the incremental redisplay protocol, and so stream-accept on an accepting-values-stream can now pass the encapsulating stream to accept-present-default. This removes a bit of the ugliness from the accept-present-default methods for displaying gadgets in general.
I'm still trying to figure out how to make nested calls to accept work (e.g. for a user defined accept-present-default that accepts a few primitive types) without resorting to nested accepting-values calls.
I've also attached a newer avg.lisp that should be fully working if a bit in need of cleanup. Now supported are text-field and text-editor gadgets.
Clinton Ebadi clinton@unknownlamer.org writes:
I think the patch is good enough to merge into cvs. I'm finishing up the last few issues with the gadget dialog views now, and should have a set of fairly clean working patches in a few days.
Excellent!
I think that, once this is in, we should freeze and make a release quickly, this is actually pretty useful and significant stuff.
Clinton Ebadi clinton@unknownlamer.org writes:
Ok, I have now attached a third revision of the patch to add the infrastructure needed to support gadget based accepting-values dialogs. The big change is that encapsulating streams now support the incremental redisplay protocol, and so stream-accept on an accepting-values-stream can now pass the encapsulating stream to accept-present-default. This removes a bit of the ugliness from the accept-present-default methods for displaying gadgets in general.
Bah, I should have tested the encapsulating stream stuff with something a bit fancier than the address book and my demo. Drei is very unhappy with being passed an encapsulating stream so I have to add proxy methods for panes and stream panes (not required by the spec, but since a pane is a sheet is a stream ...).
Greetings,
I ironed out a few bugs in my implementation some weeks ago and almost have my gadget based dialog code working now, but my laptop decided to mysteriously die (someone spilled a very sugary drink into my laptop case and I put my laptop into the case...) so I've been unable to code for a bit as my only other machine lacks a monitor at present. I managed to fix my laptop yesterday (the Internet is a wonderful place where one can find technician service manuals).
I intend to have the patch working with equivalent functionality to the current accepting-values by the end of July. Right now I'm focused on getting clisp and ffcall working on EABI ARM and packaged for openembedded (mcclim on the neo freerunner!) and the intial work for a startup I recently joined so it will be a week or two before I have time to finish ironing out the last few issues.
My big question now is: is it ok if the gadget based accepting-values is not user extensible? I fetched the CLIM mailing list archives and it seems that the spec is indeed woefully underspecified in this area, and so making accepting-values user extensible will require shaping up the current implementation and exposing bits of the protocol as a mcclim extension. I am willing to work on this later, but right now am lacking the time to undertake such a large projet (the economy is cruel and demands that I do things for it lest I starve). Perhaps in September I'd be able to make things extensible, but I figure that a nonextensible gadget based accepting-values is nicer than a nonextensible text field based accepting-values.
Clinton Ebadi clinton@unknownlamer.org writes:
My big question now is: is it ok if the gadget based accepting-values is not user extensible?
Fine by me. My previous statements were based on the fallacious assumption that the spec already specified most of what was needed, and if that is not the case a non-extensible implementation is better than none at all.
-
Clinton Ebadi -
Paul Werkowski -
Troels Henriksen