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.
palette.entries = palette.entries
palette.entries.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 = palette.entries.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! :-)
Gimp-developer mailing list