Hi Lars-Peter, On Mon, Jun 16, 2008 at 4:37 AM, Lars-Peter Clausen <lars@xxxxxxxxxxx> 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----- > _______________________________________________ > Gimp-developer mailing list > Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > -- David _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
