Hi Lars-Peter,

On Mon, Jun 16, 2008 at 4:37 AM, Lars-Peter Clausen <[EMAIL PROTECTED]> wrote:
> Hash: SHA1
> Hi,
> a short update what I did during the last few weeks.
> * I started with moving the package structure to a more hierarchical one. With
>  a gimp package on top and several subpackages like gimp.colors, gimp.enums,
>  gimp.ui.
> * I also changed gimp.enums to use GEnum objects instead integers for the 
> enums.
> * Gradient, Brush, Palette and Pattern objects have been mapped in pure 
> python.
>  Although I'm not that happy with gimp.Gradient and gimp.Palette:
>  The problem is that in python you can not copy a object implicitly by value.
>  Assigning a object to a name copies the reference and increases the refcount.
>  Image the following code:
>  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.
I disagree. From the code you showed above, changing
palette.entries[1] should effect palette.entries[0], but not vice

Anyway, I really recommend following NumPy's lead here; it's a tried
and tested solution in it's field (array manipulation), and it's a
pleasure to use -- I use it myself for manipulating colors, palettes,
and images.

NumPy approach looks like:

> palette.entries[0] = palette.entries[1] # copy palette entry

>  in gimp palette entries can only accessed by their index. So I ended up
>  writing some code that tracks which GradientEntry is assigned to what 
> indices.
>  The problem starts when a script uses gimp.pdb.gimp_palette_delete_entry in
>  parallel. A Gradient object can not be notified when a entry is deleted so
>  the indices get all wrong.
>  Something similar is true for the gradient wrapper.
> * I added a gimp.context module that wraps all the gimp_context_* functions.
This, and the gradient+palette wrappers, are very good news (I'll
still end up wrapping your modules, because I need custom behaviour
for fg and bg attributes, as well as additional functionality for
palettes and gradients. I expect for most other people, your new
classes will be sufficient by themselves). I look forward to seeing
the final result of your good work on this.

Oh! Are they (Gradient, Palette, Pattent) subclassable? If not, no big
deal; it just would be nice to be able to add methods.

I'm also curious about the Pattern interface. Does it allow you to
directly replace the pixels of a pattern with new pixels, or not?

> * Added wrapper code for most of the missing gimp widgets. So gimp.ui is
>  almost complete now except for a problem with Preview objects.
>  Also some methods need a more pythonic interface.
> * Added a unittest that test if the wrapped widget methods at least do not
>  crash and accept the right parameters.
> * Additionally I found and fixed some bugs in pygimp.
> What comes next:
> * Do something about the problems with gimp.Gradient and gimp.Palette 
> described
>  above.

As I said before, I recommend NumPy's approach highly. Assigning by
reference in such a way is too potent an opportunity for confusion.
Say that I do

palette.entries[0] = palette.entries[1]
palette.entries[1] = palette.entries[2]
palette.entries[2] = palette.entries[3]

Then assigning to palette.entries[3] should change 0,1,2, and 3.
 That seems very confusing and prone to non-obvious side-effects.

(oh, BTW, palette[index].color sounds better than
palette.entries[index].color to me. Is there any reason that this
could not work?)

> * 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.
> * The pygobject system complains when a object is not constructable with
>  properties. So I'll look into porting the widgets that don't support it, but
>  I will need some advice how to it the right way.
> * In my opinion the error messages in pygimp-pdb are a bit unspecific. So I'll
>  try to rewrite parts in pygimp-pdb.c to give better error messages.
> Lars
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> Avt349hZp0rImYXhrTzXUcc=
> =/DOD
> _______________________________________________
> Gimp-developer mailing list
> Gimp-developer@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Gimp-developer mailing list

Reply via email to