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[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!  :-)

Gimp-developer mailing list

Reply via email to