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
->

Hi Lars-Peter,

On Mon, Jun 16, 2008 at 4:37 AM, Lars-Peter Clausen wrote:

-----BEGIN PGP SIGNED MESSAGE----- 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 versa.

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

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIVWh6BX4mSR26RiMRAl+oAJ49fEOfqkANQTuuKS8mDzoueGLWFQCfY+KY Avt349hZp0rImYXhrTzXUcc=
=/DOD
-----END PGP SIGNATURE-----

Hi,

sorry for the late reply, I have been on vacation and I am slowly catching up on the emails now...

On Sun, 2008-06-15 at 21:07 +0200, Lars-Peter Clausen wrote:

* 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.

I don't think libgimpmath is of much use for plug-in authors using Python.

* 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.

Can you tell us which GIMP widgets are problematic?

Sven

Hi,

On Fri, 2008-07-04 at 01:16 +0200, Lars-Peter Clausen wrote:

List of those widgets:
GimpColorSelector, GimpColorScales, GimpColorNotebook, GimpImageComboBox, GimpEnumComboBox, GimpDrawableComboBox, GimpChannelComboBox, GimpEnumStore, GimpLayerComboBox, GimpMemsizeEntry, GimpOffsetArea, GimpPreview, GimpScrolledPreview, GimpSelectButton, GimpSizeEntry, GimpUnitMenu, GimpVectorsComboBox

We should add the necessary construct properties then and move the code in new to a constructor method. Patches for this are very welcome. Does anyone want to work on this? It's a simple task, but it would definitely help any language bindings for GIMP widgets.

Sven