GNOME Bugzilla – Bug 543021
Python GeglRectangle goodness
Last modified: 2011-09-03 18:46:37 UTC
I'd like to keep adding some features to the Python Gegl bindings - and I wouldn't matter if I could do that somewhat loosely up to some Gegl API freeze horizon. Yosh has set up thigns so that pure python enhancements only have to go into the fifthleg.py file to override the authomatic C bindings. I plan to add some behavior to bring up Gegl introspection closer to the python API using this. For now, I just made a python wrapper for GeglRectangle which, brings the Rectangle class closer to the level of usability a python coder would expect, and offers a taste of what can be done. The idea is slowly get to have nice, self documented, feature full python bindings, unlike most bindings built only with automatic wrappers (gtk+, qt), or made in C only, in which case adding things as simple as accepting different parameters for initializing the class is a PITA.
Created attachment 114566 [details] [review] Patch implementing GeglRectangle Wrapper in Python the wrapper here implements, besides what is done in the pure C call to GeglRectangle available without it: - Instantiating a rectangle from a len(4) sequence - not only with four separate paramenters; - Rectangle __add__ allowing one to add a 2 tuple (creates a new, translated rectangle), or a 4 tuple or rectangle (generating the smallest rectangle contaning both operators) - A __mul__ method allowing for rectangle scaling with a multplication for a scalar - A __repr__ method whidh will show the rect. components: handy for people using gegl at the python console. - A __getslice__ providing a handy way to retrieve the 4 rect. components.
Doesn't hurt to commit this I guess. You have commit access, right? Or was it you who lost your SSH key?
Still applies and works, so I committed and pushed it now. Why not. http://git.gnome.org/browse/gegl/commit/?id=63e03ba259d32cebdd6155d4e9c5d9bc662d0e4b Note that in the longer term we will be going for GObject Introspection for bindings. See bug #645822