Hi,
can you please move mcclim-images into its own system file mcclim.asd, and mcclim-images-FOO into their own files mcclim-images-FOO.asd?
Right now, it's not possible to load the clim-listener system without having loaded the mcclim system manually before.
(It would be possible to change the order of the dependencies in clim-listener.asd so that this problem is avoided, but ISTR that older versions of ASDF expected the opposite order, and when we discussed this on #lisp, the consensus was that any system that user code would depend on needs its own .asd file.)
Thanks, David
Incidentally, I still don't grok the added value of the mcclim-images wrapper (other than as a single interface for loading multiple file types) versus having the load functions return CLIM designs correctly. Further, the interface is broken. I favor the nuclear option.
Quoting Andy Hefner (ahefner@gmail.com):
Further, the interface is broken.
I think that most code in mcclim-images is valuable, assuming the system definition issues can be sorted out. The image loading API also seems nice, but admittedly the drawing API needs to be worked on.
If you don't like the currently proposed functions, would you accept a version of rgb-images that use draw-image (again), but this time with correct handling of transformed designs?
It's really just a question of getting the output recording right.
I favor the nuclear option.
... because we must not allow an output recording gap?
d.
"Andy Hefner" ahefner@gmail.com writes:
Incidentally, I still don't grok the added value of the mcclim-images wrapper (other than as a single interface for loading multiple file types) versus having the load functions return CLIM designs correctly. Further, the interface is broken. I favor the nuclear option.
I have come to favor the proposed bitmap extension in CLIM 2.0, which seems to be actually implemented in CLIM 2.2. I would support an obliteration of MCCLIM-IMAGES and an implementation of the bitmap-pattern protocol, but not one without the other.