On Sunday 15 June 2008, Lars-Peter Clausen wrote: Thank you for the e-mail -- there is a lot fo thing going on. I am not shure if I understood the exact nature of the palletes and gradients problems you describe - but you have to take care to let they behave like python - even if it is not the most intuitive thing when one does not understand what python is doing. if " palette.entries[0] = palette.entries[1] palette.entries[0].color = gimp.colors.RGB(0, 0, 0) From a python point of view it should change the color of entry 0 and 1." This is what should happen in pygimp. We should introduce a copy methotd to gimp colors, if they don't have. So one would do: palette.entries[0] = palette.entries[1].copy() to duplicate the entry. (this won't be a problem, and will be even less of an issue if it is properly documented on the palette and gradient classes doc strings ) > * I have been looking into wrapping libgimpmath. But I'm not sure > how to handle it. The matrix and vectors code looks incomplete and > inconsistent. Some objects are GObjects others are not. hmmm..Python cando it is own math -- but it may be possible that are function calls that use the matrix structs and others as they are defined in libgimpmath - maybe you could use "ctypes" there? It is an easy wrapping around C dynamic libraries taht is made in python only at runtime (Ctypes is part of standard python distro as of python 2.5 so it won't increase our dependencies). On the other hand, if the structs desscribed in the libgimpmap/*h files are not usefull for other function calls made from python, just docuemtning what is available and suggesting how to do it in NumPy would be enough, IMO. Thank you for the post. I think it is a nice oportunity for everyone to see the money they make google win with their eyeballs is being well spent! :-) js -><- _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
