[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gimp-developer
Subject:    Re: [Gimp-developer] GSoC Status Report for pygimp
From:       "David Gowers" <00ai99 () gmail ! com>
Date:       2008-06-16 1:42:30
Message-ID: 23f4e3390806151830r79d59887va3d35bd38b78bdeb () mail ! gmail ! com
[Download RAW message or body]

Hi Lars-Peter,

On Mon, Jun 16, 2008 at 4:37 AM, Lars-Peter Clausen <lars@laprican.de> 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@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
>

--
David
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[prev in list] [next in list] [prev in thread] [next in thread]