I've cc'ed John Stowers, who was thinking of adding the introspection annotations to GooCanvas. Maybe if you ask nicely...

I don't know enough about them myself to add them.

Though I haven't changed the GooCanvas API much at all for gtk3, so it shouldn't be much work to update the current bindings.

I think i'll take contact with him ;)
Btw, it seems quite easy to add such annotations : 

http://live.gnome.org/GObjectIntrospection
http://live.gnome.org/GObjectIntrospection/Annotations (i didn't know much about them too)

The problem with updating current bindings, is that pyGTK do not support GTK3, so you have to use gobject-introspection if you want to port yout python app to GTK3.

Hi all,

I've made a start at trying to add GObject Introspection bindings to GooCanvas. Unfortunately I've run into a few issues, and I'm not knowledgeable enough about GI to know the best way to fix them.

Problems:
--------

1) If we use the C prefix "goo_", then we end up with classes named "CanvasItemSimple", "CanvasText", "CanvasPolyline" etc. On the other hand, if we use the C prefix "goo_canvas_" then we get the nicer (IMO) class names "ItemSimple", "Text" and "Polyline" and so on. Unfortunately, we can't use this prefix because then the class named "GooCanvas" would have no name...

2) The goo_canvas_<foo>_new() functions have a trick whereby if you supply a parent object as the first argument, then the parent owns the object and it is returned to you unreferenced (i.e. it should be (transfer none) in GI terms). On the other hand, if parent is NULL then you own the new object, i.e. the annotation should be (transfer full). I don't know of any way to represent this using annotations.

The best solution I've thought of so far is to add a (skip) annotation to the parent field, so that bindings always supply NULL, and the resulting object is then owned by the caller, who has to set the "parent" property directly.

Having said all that, bindings aren't really supposed to use _new() functions anyway, but rather use a "native" constructor that wraps g_object_new() and sets various GObject properties.

3) GooCanvasPoints is a bit of a strange beast. It's a boxed struct, and therefore a value type as far as GI is concerned, but implements its own reference counting. It stores an array of doubles, but the num_points field stores the number of *pairs*. PyGI can't access struct fields, so there's no way to actually store anything in it from Python.

We could probably just (skip) the whole thing for introspection purposes, except that it's needed for GooCanvasPolyline, which otherwise can't be constructed with a native constructor. (Or rather, it can be constructed but will have no data.) I think adding a new method along the lines of

void goo_canvas_polyline_set_points(gdouble *coords, int num_coords);

would solve this: it could then be called from Python as

CanvasPolyline.set_points( [ 0, 0, 100, 100 ] ),

and we wouldn't have to bother with GooCanvasPoints.

4) I think this is a Python-only issue, but the magic glue code that joins PyCairo types to introspected Cairo types doesn't seem to work for cairo.Matrix (aka cairo_matrix_t). This means that goo_canvas_item_set_transform() and friends can't use used properly from Python.



I can supply patches of my work-in-progress if you like, or otherwise upload to a public git repo somewhere (I don't have Gnome git access). Let me know if this would be helpful.

Tristan

(In reply to comment #3)
> Hi all,
> 
> I've made a start at trying to add GObject Introspection bindings to GooCanvas.

Excellent. You look to have got further than me before time commitments took me away.

> Unfortunately I've run into a few issues, and I'm not knowledgeable enough
> about GI to know the best way to fix them.
> 
> Problems:
> --------
> 
> 1) If we use the C prefix "goo_", then we end up with classes named
> "CanvasItemSimple", "CanvasText", "CanvasPolyline" etc. On the other hand, if
> we use the C prefix "goo_canvas_" then we get the nicer (IMO) class names
> "ItemSimple", "Text" and "Polyline" and so on. Unfortunately, we can't use this
> prefix because then the class named "GooCanvas" would have no name...

Does the rename to annotation work here?

> 
> 2) The goo_canvas_<foo>_new() functions have a trick whereby if you supply a
> parent object as the first argument, then the parent owns the object and it is
> returned to you unreferenced (i.e. it should be (transfer none) in GI terms).
> On the other hand, if parent is NULL then you own the new object, i.e. the
> annotation should be (transfer full). I don't know of any way to represent this
> using annotations.
> 
> The best solution I've thought of so far is to add a (skip) annotation to the
> parent field, so that bindings always supply NULL, and the resulting object is
> then owned by the caller, who has to set the "parent" property directly.

I agree. We can override the constructor in python can call set parent where appropriate.

> 
> Having said all that, bindings aren't really supposed to use _new() functions
> anyway, but rather use a "native" constructor that wraps g_object_new() and
> sets various GObject properties.
> 
> 3) GooCanvasPoints is a bit of a strange beast. It's a boxed struct, and
> therefore a value type as far as GI is concerned, but implements its own
> reference counting. It stores an array of doubles, but the num_points field
> stores the number of *pairs*. PyGI can't access struct fields, so there's no
> way to actually store anything in it from Python.

I though pygi could access struct fields. Maybe the scanner is not picking it up correctly

> 
> We could probably just (skip) the whole thing for introspection purposes,
> except that it's needed for GooCanvasPolyline, which otherwise can't be
> constructed with a native constructor. (Or rather, it can be constructed but
> will have no data.) I think adding a new method along the lines of
> 
> void goo_canvas_polyline_set_points(gdouble *coords, int num_coords);
> 
> would solve this: it could then be called from Python as
> 
> CanvasPolyline.set_points( [ 0, 0, 100, 100 ] ),
> 
> and we wouldn't have to bother with GooCanvasPoints.

We can do an override either way in python.

> 
> 4) I think this is a Python-only issue, but the magic glue code that joins
> PyCairo types to introspected Cairo types doesn't seem to work for cairo.Matrix
> (aka cairo_matrix_t). This means that goo_canvas_item_set_transform() and
> friends can't use used properly from Python.
> 
> 
> 
> I can supply patches of my work-in-progress if you like, or otherwise upload to
> a public git repo somewhere (I don't have Gnome git access). Let me know if
> this would be helpful.

If you push this to github I can take care and make sure it gets to gnome.org.

Either way, Id like to take a look.

John

(In reply to comment #4)

> > 1) If we use the C prefix "goo_", then we end up with classes named
> > "CanvasItemSimple", "CanvasText", "CanvasPolyline" etc. On the other hand, if
> > we use the C prefix "goo_canvas_" then we get the nicer (IMO) class names
> > "ItemSimple", "Text" and "Polyline" and so on. Unfortunately, we can't use this
> > prefix because then the class named "GooCanvas" would have no name...
> 
> Does the rename to annotation work here?

I've just tried it in the comment block for the _GooCanvas struct, and it doesn't seem to do anything. Perhaps this is the wrong place though?

> > 
> > The best solution I've thought of so far is to add a (skip) annotation to the
> > parent field, so that bindings always supply NULL, and the resulting object is
> > then owned by the caller, who has to set the "parent" property directly.
> 
> I agree. We can override the constructor in python can call set parent where
> appropriate.

Okay, I'll go through and add these annotations.

> > 
> > Having said all that, bindings aren't really supposed to use _new() functions
> > anyway, but rather use a "native" constructor that wraps g_object_new() and
> > sets various GObject properties.
> > 
> > 3) GooCanvasPoints is a bit of a strange beast. It's a boxed struct, and
> > therefore a value type as far as GI is concerned, but implements its own
> > reference counting. It stores an array of doubles, but the num_points field
> > stores the number of *pairs*. PyGI can't access struct fields, so there's no
> > way to actually store anything in it from Python.
> 
> I though pygi could access struct fields. Maybe the scanner is not picking it
> up correctly

My mistake, PyGI can access fields, but for some reason GooCanvasPoints.coords is introspected as having type double rather than array-of-double (which is odd, as its C type is gdouble*).

However, even if Python could set the coords field directly, it probably wouldn't be the right thing to do, since GooCanvas assumes that the slice allocator has been used and calls g_slice_free() on the array in the "destructor" of GooCanvasPoints. That probably won't be the case if Python has allocated the array, and certainly won't be the case for all of GJS, Seed etc...

> > 
> > We could probably just (skip) the whole thing for introspection purposes,
> > except that it's needed for GooCanvasPolyline, which otherwise can't be
> > constructed with a native constructor. (Or rather, it can be constructed but
> > will have no data.) I think adding a new method along the lines of
> > 
> > void goo_canvas_polyline_set_points(gdouble *coords, int num_coords);
> > 
> > would solve this: it could then be called from Python as
> > 
> > CanvasPolyline.set_points( [ 0, 0, 100, 100 ] ),
> > 
> > and we wouldn't have to bother with GooCanvasPoints.
> 
> We can do an override either way in python.
> 

While Python is my main interest, it would be nice if we could do this in a way that makes things easy from JavaScript (etc) too


> > I can supply patches of my work-in-progress if you like, or otherwise upload to
> > a public git repo somewhere (I don't have Gnome git access). Let me know if
> > this would be helpful.
> 
> If you push this to github I can take care and make sure it gets to gnome.org.
> 

I've put this up on Gitorious:

http://gitorious.org/goocanvas/goocanvas

(the 'introspection' branch)

Cheers,

Tristan

I pushed an improved branch here

http://git.gnome.org/browse/goocanvas/log/?h=introspection

I added some python overrides to clean up the API. In particular to work around vargs in most of the constructors (xxx_new). The GooCanvas.py should be placed in the python2.7/dist-packages/gi/overrides directory.

The demo tests some of the harder classes, like path and polyline to show how the overrides work. Seems to work well here.

Comments appreciated.

I also couln't get rename to work, so if we want to keep API compat with pygoocanvas we might need to rename all the classes in the override. Or people can just handle it...

Oh, and the overrides need to be integrated into the build system. The overrides dir is specified in the pygobject pkg-config file.

Thanks for doing this. It's starting to look good.

The only thing that concerns me a bit is the overrides stuff. Is it normal to put that in with the original package? I worry a bit about all the different possible language bindings.

A separate directory for bindings stuff would be good! Maybe one per language binding. See what other packages do.

(In reply to comment #8)
> Thanks for doing this. It's starting to look good.
> 
> The only thing that concerns me a bit is the overrides stuff. Is it normal to
> put that in with the original package? I worry a bit about all the different
> possible language bindings.
> 
> A separate directory for bindings stuff would be good! Maybe one per language
> binding. See what other packages do.

Yeah, thats the plan. I was going to put it in bindings/python/GooCanvas.py. So far Python is the only one that has runtime overrides like this, although there is a patch in review for gjs that would allow similar functionality.

Ive seen this approach (shipping the override with the original lib) in the new clutter bindings and some Ubuntu specific stuff.

Hi all,

I've pushed a few updates to my Gitorious repo at

http://gitorious.org/goocanvas/goocanvas

The add more annotations, and fix all but one warning from g-ir-scanner[1]. I've also ported the demo.py file to JavaScript (both GJS and Seed flavours) for testing purposes.

The good news is, we're getting there! The remaining problems I can see are:

1) The CanvasPoints API can't be used at all from GJS, and is a bit unpleasant to use from Seed. Overrides solve this in Python, but I think it would be better to have a solution in GooCanvas (see my PolyLine API suggestion in comment 3)

2) The GooCanvasItem.[get|set]_transform() functions, which operate on Cairo matrices, don't work properly from any language, so I can only assume that this is a GI bug.

3) Using any enums from GooCanvas (for example CanvasAnchorType) from Python pops up a strange warning:

"expected enumeration type GooCanvasAnchorType, but got CanvasAnchorType instead"

I don't know whether this is a PyGI bug or something not being annotated correctly; it doesn't happen in GJS or Seed.


I've ported a reasonably large internal app of ours from pygoocanvas to PyGI and the new bindings; other than the get/set_transform() thing, everything seems to be working :-)

Cheers,

Tristan


[1] The one that's left is regarding a non-namespaced #define, which probably shouldn't really be in a public header

Ignore issue (3) above, now fixed.

(In reply to comment #10)
> Hi all,
> 
> I've pushed a few updates to my Gitorious repo at
> 
> http://gitorious.org/goocanvas/goocanvas

I pushed this to GNOME with one more commit to move all the demos and overrides to bindings/{python,gjs,seed}/

I still need to do the autotools foo to extract the python override directory from the pygobject makefile.

> 
> The add more annotations, and fix all but one warning from g-ir-scanner[1].
> I've also ported the demo.py file to JavaScript (both GJS and Seed flavours)
> for testing purposes.
> 
> The good news is, we're getting there! The remaining problems I can see are:
> 
> 1) The CanvasPoints API can't be used at all from GJS, and is a bit unpleasant
> to use from Seed. Overrides solve this in Python, but I think it would be
> better to have a solution in GooCanvas (see my PolyLine API suggestion in
> comment 3)

I wonder if it should be in the form of extending the api to GooCanvasPoints (like I already did once to make the python binding possible)

goo_canvas_points_set_points(points, gdouble *coords, int num_coords);

then

g_object_set(polyline, "points", points, NULL)

note that part of my reason for doing the GooCanvasPoints override how I have done is to maintain compatibility with pygoocanvas. I am also surprised to see that gjs does not support the

GooCanvas.CanvasPolyline.new_line

form, as the GObject.other_constructor_returning_new_instance idiom is common in GObject code. What does gjs do for things like Gio.File.new_from_xxx?

(In reply to comment #12)
> (In reply to comment #10)
> > Hi all,
> > 
> > I've pushed a few updates to my Gitorious repo at
> > 
> > http://gitorious.org/goocanvas/goocanvas
> 
> I pushed this to GNOME with one more commit to move all the demos and overrides
> to bindings/{python,gjs,seed}/

Cool, this is now in the Gitorious repo along with a commit that fixes a typo in the extension to the Seed demo file.

> 
> I still need to do the autotools foo to extract the python override directory
> from the pygobject makefile.
> 

I was thinking about this: what happens to the overrides file if the user has parallel installs of Python2 and Python3? Or (as I did today) installs Python3 after GooCanvas? The overrides for Gtk et al are shipped with PyGObject, perhaps we should ask if the GooCanvas overrides can live there too? 

> > 
> > The add more annotations, and fix all but one warning from g-ir-scanner[1].
> > I've also ported the demo.py file to JavaScript (both GJS and Seed flavours)
> > for testing purposes.
> > 
> > The good news is, we're getting there! The remaining problems I can see are:
> > 
> > 1) The CanvasPoints API can't be used at all from GJS, and is a bit unpleasant
> > to use from Seed. Overrides solve this in Python, but I think it would be
> > better to have a solution in GooCanvas (see my PolyLine API suggestion in
> > comment 3)
> 
> I wonder if it should be in the form of extending the api to GooCanvasPoints
> (like I already did once to make the python binding possible)
> 
> goo_canvas_points_set_points(points, gdouble *coords, int num_coords);
> 
> then
> 
> g_object_set(polyline, "points", points, NULL)
> 
> note that part of my reason for doing the GooCanvasPoints override how I have
> done is to maintain compatibility with pygoocanvas. I am also surprised to see
> that gjs does not support the
> 
> GooCanvas.CanvasPolyline.new_line
> 
> form, as the GObject.other_constructor_returning_new_instance idiom is common
> in GObject code. What does gjs do for things like Gio.File.new_from_xxx?

GJS has no problem with named constructors in general The problem in this case is that Polyline.new_line() takes varargs in C, which means it gets flagged as unusable by the introspection scanner, as GI can't handle varargs (yet?). In fact, this is the case for just about every C constructor in the library.

The problem with GooCanvasPoints is that GJS requires a boxed struct to have a C constructor that takes no parameters. I don't know why -- this limitation doesn't exist in Seed. So at the moment (AFAIK) it's not possible to create a GooCanvasPoints at all in GJS.

However, it turns out that my idea to use a plain array of doubles won't work from GJS either, as having tested it, it doesn't seem to automatically convert from JS arrays to C arrays when doubles are involved (it only works for integer types). So I don't know what to do.

A new C constructor for Polyline that's the same as new_line() but without the varargs would solve the problem of easily constructing a simple straight line, something like:

goo_canvas_polyline_new_simple(gdouble x1, gdouble y1, gdouble x2, gdouble y2);

You still wouldn't be able to construct a complex path with multiple points in GJS, but we could put a note in the docs warning people of this and advising them to use GooCanvasPath instead.

> > to bindings/{python,gjs,seed}/
> 
> Cool, this is now in the Gitorious repo along with a commit that fixes a typo
> in the extension to the Seed demo file.

Oops, that was silly of me.

> 
> GJS has no problem with named constructors in general The problem in this case
> is that Polyline.new_line() takes varargs in C, which means it gets flagged as
> unusable by the introspection scanner, as GI can't handle varargs (yet?). In
> fact, this is the case for just about every C constructor in the library.

Again, oops, not a good morning. I forgot I faked new_line() in the override for the very reasons you mention.

> 
> The problem with GooCanvasPoints is that GJS requires a boxed struct to have a
> C constructor that takes no parameters. I don't know why -- this limitation
> doesn't exist in Seed. So at the moment (AFAIK) it's not possible to create a
> GooCanvasPoints at all in GJS.
> 
> However, it turns out that my idea to use a plain array of doubles won't work
> from GJS either, as having tested it, it doesn't seem to automatically convert
> from JS arrays to C arrays when doubles are involved (it only works for integer
> types). So I don't know what to do.
> 
> A new C constructor for Polyline that's the same as new_line() but without the
> varargs would solve the problem of easily constructing a simple straight line,
> something like:
> 
> goo_canvas_polyline_new_simple(gdouble x1, gdouble y1, gdouble x2, gdouble y2);

I think these special hacks should be on the GooCanvasPoints object, and then just pass the GooCanvasPoints struct through the normal constructor (as is done currently).

It is a shame about the gjs limitation for double arrays. I know python supports this, so I think it would make sense to have a special constructor like

goo_canvas_points_new_from_points(double *pts, int num_points, GError *error)

This would be handled nicely in python and I suspect the gjs limitation will be removed before too long.

> 
> You still wouldn't be able to construct a complex path with multiple points in
> GJS, but we could put a note in the docs warning people of this and advising
> them to use GooCanvasPath instead.

Or goo_canvas_points_set()

What do you think?

John

Note that GooCanvasPoints was only meant as a convenient way to get/set all the polyline points via a property.

It obviously isn't working for the bindings! So maybe just ignore it and add
any necessary functions to GooCanvasPolyline directly.

e.g.
  void goo_canvas_polyline_set_points (poly, int num_points, gdouble *coords);

  int  goo_canvas_polyline_get_num_points (poly);
  void goo_canvas_polyline_set_num_points (poly, int num_points);
    - this would keep existing points if possible.

  void goo_canvas_polyline_set_point (poly, int point_num, gdouble x, gdouble y);
  void goo_canvas_polyline_get_point (poly, int point_num, gdouble *x, gdouble *y);

I think they can all be added without breaking any API, and should be easier to wrap.

John: I've pushed another annotation tweak to the introspection branch on gitorious if you want to pick it up.

(In reply to comment #15)
> Note that GooCanvasPoints was only meant as a convenient way to get/set all the
> polyline points via a property.
> 
> It obviously isn't working for the bindings! So maybe just ignore it and add
> any necessary functions to GooCanvasPolyline directly.
> 
> e.g.
>   void goo_canvas_polyline_set_points (poly, int num_points, gdouble *coords);
> 
>   int  goo_canvas_polyline_get_num_points (poly);
>   void goo_canvas_polyline_set_num_points (poly, int num_points);
>     - this would keep existing points if possible.
> 
>   void goo_canvas_polyline_set_point (poly, int point_num, gdouble x, gdouble
> y);
>   void goo_canvas_polyline_get_point (poly, int point_num, gdouble *x, gdouble
> *y);
> 
> I think they can all be added without breaking any API, and should be easier to
> wrap.

I agree with this. I've hacked up a very quick example with an API along these lines, available in the polyline-api branch on Gitorious.

It adds a new property on GooCanvasPolyline called "coords", that takes a GArray of doubles, along with get_coords() and set_coords() functions that also operate on GArrays.

Because PyGI has automatic conversion of Python lists/tuples to GArrays, it means you can create a new Polyline like this in Python:

   GooCanvas.CanvasPolyline(
        parent = root,
        coords = [ 0, 0, 
                   100, 100,
                   100, 0],
        # Other properties as normal
    )

Also,

    CanvasPolyline.set_coords([0, 0, 100, 100])

works as expected, as does

    CanvasPolyline.props.coords = [ 0, 0, 100, 100 ].

I think this is actually nicer than the way it's done in the overrides with GooCanvasPoints, but maybe that's just me.

GJS had automatic conversion of JS arrays to GArrays, but as mentioned this doesn't work for doubles. If/when this gets fixed, the same API can be used there. In the mean time, there's also a new function

   goo_canvas_polyline_add_point(polyline, gdouble x, gdouble y)

which does what you'd expect, and works with all bindings.


The code in Gitorious is a quick-and-dirty hack to flesh out the API and see what works with bindings. In particular, it ignores all the GooCanvasPolylineModel stuff, because frankly I don't understand that :-). 

Comments appreciated.

I think these belong as functions on the GooCanvasPoints struct (or at least should exist there too). This is both for compatibility with pygoocanvas, and because it seems like a layering violation to have them on GooCanvasPolyline.

But then again, Damon said that GooCanvasPoints mostly exists to make bindings easier, so I guess it is up to him.

Damon?

p.s. I pushed gitorious/introspection to GNOME again.

I don't mind adding stuff to GooCanvasPoints for compatibility.

I'd say do that plus the function:
  void goo_canvas_polyline_set_points (poly, int num_points, gdouble *coords);

So at least you have the option of slightly simpler code.


We can maybe add other stuff later once we know what works best for all bindings.

http://blogs.gnome.org/nacho/2011/06/13/announce-pygobject-2-28-6-released/

New pygobject release which seems to fix some issues you might encouter.

Can you give installatio ninstruction to test introspection branch ? So i can start porting openshot and find some bugs.

I just run ./autogen.sh, make, make install but introspection didn't work (but goocanvas seems to be installed)

(In reply to comment #20)
> Can you give installatio ninstruction to test introspection branch ? So i can
> start porting openshot and find some bugs.

The introspection branch in gnome git. We still have to finish the odd rough parts discussed above, but it should be surprisingly usable already.

> 
> I just run ./autogen.sh, make, make install but introspection didn't work (but
> goocanvas seems to be installed)

You need to tell it where to find the typelibs. Either install to /usr (not recommended) or install to somewhere else (like /tmp or /usr/local) and set GI_TYPELIB_DIR=/path/to/GooCanvas.typelib

When i compile, i dont have any file related to gobject introspection (i branched the introspection branch correctly). No Goocanvas.typelib.

And where have i to set GI_TYPELIB_DIR=/path/to/GooCanvas.typelib ? I'm not very familiar with autotools or build system. Used to python.

Here's what i've done :

- Branch introspection with git
- cd ~/introspection
-.autogen.sh --prefix=/usr/local
- make
- sudo make install

The tree wommand on /usr/local :

/usr/local
|-- bin
|-- etc
|-- games
|-- include
|   `-- goocanvas-2.0
|       |-- goocanvasellipse.h
|       |-- goocanvasenumtypes.h
|       |-- goocanvasgrid.h
|       |-- goocanvasgroup.h
|       |-- goocanvas.h
|       |-- goocanvasimage.h
|       |-- goocanvasitem.h
|       |-- goocanvasitemmodel.h
|       |-- goocanvasitemsimple.h
|       |-- goocanvasmarshal.h
|       |-- goocanvaspath.h
|       |-- goocanvaspolyline.h
|       |-- goocanvasrect.h
|       |-- goocanvasstyle.h
|       |-- goocanvastable.h
|       |-- goocanvastext.h
|       |-- goocanvasutils.h
|       `-- goocanvaswidget.h
|-- lib
|   |-- libgoocanvas-2.0.a
|   |-- libgoocanvas-2.0.la
|   |-- libgoocanvas-2.0.so -> libgoocanvas-2.0.so.9.1.1
|   |-- libgoocanvas-2.0.so.9 -> libgoocanvas-2.0.so.9.1.1
|   |-- libgoocanvas-2.0.so.9.1.1
|   `-- pkgconfig
|       `-- goocanvas-2.0.pc
|-- man
|-- sbin
|-- share
|   |-- locale
|   |   |-- en_GB
|   |   |   `-- LC_MESSAGES
|   |   |       `-- goocanvas2.mo
|   |   |-- es
|   |   |   `-- LC_MESSAGES
|   |   |       `-- goocanvas2.mo
|   |   |-- ja
|   |   |   `-- LC_MESSAGES
|   |   |       `-- goocanvas2.mo
|   |   `-- sv
|   |       `-- LC_MESSAGES
|   |           `-- goocanvas2.mo
|   `-- man -> ../man
`-- src

I used locate too, but didn't find anything related too goocanvas elsewhere.

Thanks for your help !

(In reply to comment #22)
> When i compile, i dont have any file related to gobject introspection (i
> branched the introspection branch correctly). No Goocanvas.typelib.

Install the dependencies and ./configure with --enable-introspection (or similar)

didn't work to

./configure --enable-introspection after ./autogen.sh (because it generate the configure file)
I get this error : configure: WARNING: unrecognized options: --enable-introspection

(In reply to comment #24)
> didn't work to
> 
> ./configure --enable-introspection after ./autogen.sh (because it generate the
> configure file)
> I get this error : configure: WARNING: unrecognized options:
> --enable-introspection

I was really hoping you would be able to help test this. Oh well.

I was hoping so too !

Can't you tell me exactly what you did, the command lines you type to make it working ? 

It can't be so hard :p Or maybe the makefile need some fixes ?

I started over and now it's fully functionnal. I ported most of the openshot code, it almost works ! Thanks; you've done a great job !

When will the introspection branch be merged ?

Hi,

After more porting work, it seems that i'm blocked by a bug in goocanvas introspection branch. 

The raise function seems to conflict with the standard library raise function. I tried with _raise to avoid this but it doesn't work.

Any idea ?

Thanks !

What's the actual error?

There's a GObject-Introspection hackfest happening right now in Berlin. Maybe you can get them to look at this. CCing John to get it on their radar, in case they are interested.

I'm somewhat interested though I have little time.  Please feel free to ping us on #python on gimpnet with questions.  As for the raise issue shouldn't functions be namespaced?  I would recommend never using * to import symbols in gi.

from gi.repository import GooCanvas

GooCanvas.raise(...)

^---that should avoid any namespace clashes with Python builtins and keywords though I might not be completely understanding what your issues are.

I'd like to do a new release of GooCanvas in the next week or so, so it would be good if this is ready to go in. Is there much left to do?

(In reply to comment #31)
> I'd like to do a new release of GooCanvas in the next week or so, so it would
> be good if this is ready to go in. Is there much left to do?

IMO no, Im just waiting for feedback from the goocanvas and openshot developers - both have branches using this code.

I always have this raise issue :

+ Trace 228569

Where play_head is a CanvasGroup.

I imported goocanavs correctly : from gi.repository import GooCanvas

But it still seems to conflict with python raise function. Or maybe it is another error but ireally don't understand it.

In the pygoocanvas implementation it uses "raise_" instead of raise.

So, in goocanvas one could use an alias (using #define) to that function, or a function ended in raise_ that calls raise internally. Or rename the funcion for present, like it was done to gtk.Window.raise , renamed to gtk.Window.present.

here is available all python keywords:
python 2.7: http://docs.python.org/reference/lexical_analysis.html#keywords
python 3.0: http://docs.python.org/py3k/reference/lexical_analysis.html#keywords

The rest seems to work fine.

I've just merged the branch (I hope!)

A few issues remain:

GooCanvasGrid
=============

I noticed this in src/goocanvasgrid.c

 * goo_canvas_grid_model_new:

 * @...: (skip): optional pairs of property names and values, and a terminating %NULL.

Is that a mistake? It is the only place I can see that skips the varargs.


goo_canvas_item_raise()
=======================

We could rename the C function to something like goo_canvas_item_raise_up()
if that helps solve it. We can add a #define for backwards-compatibility.


If we can sort these out I'll do a release this week.

goo_canvas_item_get_transform()
===============================

 * Returns: (skip): %TRUE if a transform is set.

Why is the return value skipped? It is quite important as if FALSE is returned the transform matrix won't be set. goo_canvas_item_get_transform_for_child()
is very similar but doesn't skip the return value.

goo_canvas_item_get_transform()/goo_canvas_item_get_transform_for_child()
=========================================================================

/**
 * goo_canvas_item_get_transform:
 * @item: an item.
 * @transform: (out callee-allocates) (transfer none): the place to store the transform.


/**
 * goo_canvas_item_get_transform_for_child:
 * @item: an item.
 * @child: a child of @item.
 * @transform: the place to store the transform.


The transform argument is used the same way for both these functions, so they
should probably have the same introspection attributes, shouldn't they?

(In reply to comment #35)
> I've just merged the branch (I hope!)
> 
> A few issues remain:
> 
> GooCanvasGrid
> =============
> 
> I noticed this in src/goocanvasgrid.c
> 
>  * goo_canvas_grid_model_new:
> 
>  * @...: (skip): optional pairs of property names and values, and a terminating
> %NULL.
> 
> Is that a mistake? It is the only place I can see that skips the varargs.
> 

I think it's a mistake, yeah. Varargs get skipped automatically anyway.

> 
> goo_canvas_item_raise()
> =======================
> 
> We could rename the C function to something like goo_canvas_item_raise_up()
> if that helps solve it. We can add a #define for backwards-compatibility.
> 

Another solution is to use the "rename" annotation.

Although having said that, I think the best solution would be for the PyGI bindings themselves to handle this; otherwise we end up in a situation where we have to start avoiding using keywords from every single target language, which is a bit of a tall order.

(Note that both flavours of JS bindings do this, renaming foo_new() to Foo.c_new() to avoid using the "new" keyword.)

(In reply to comment #37)
> goo_canvas_item_get_transform()/goo_canvas_item_get_transform_for_child()
> =========================================================================
> 
> /**
>  * goo_canvas_item_get_transform:
>  * @item: an item.
>  * @transform: (out callee-allocates) (transfer none): the place to store the
> transform.
> 
> 
> /**
>  * goo_canvas_item_get_transform_for_child:
>  * @item: an item.
>  * @child: a child of @item.
>  * @transform: the place to store the transform.
> 
> 
> The transform argument is used the same way for both these functions, so they
> should probably have the same introspection attributes, shouldn't they?

With regard to this and comment 36, I couldn't test get_transform() in Python due to bug 651043, so the annotation is basically just a guess! I don't know why I would have skipped the return value, that definitely seems wrong.

I think I left get_transform_for_child() until I could work out what the correct annotations were for get_transform(). They should of course be the same.

Since goo_canvas_item_get_transform() works in a similar way to goo_canvas_item_get_bounds() I guess the annotations should be the same,
i.e. just use 'out' for the struct to be filled in:

/**
 * goo_canvas_item_get_bounds:
 * @item: a #GooCanvasItem.
 * @bounds: (out): a #GooCanvasBounds to return the bounds in.

Any progress on the raise bug ? It really prevent me to continue the openshot port !

Thanks !

I thought that issue was covered by comment 30:

> As for the raise issue shouldn't functions be namespaced?  I would recommend
> never using * to import symbols in gi.
> 
> from gi.repository import GooCanvas
> 
> GooCanvas.raise(...)
> 
> ^---that should avoid any namespace clashes with Python builtins and keywords
> though I might not be completely understanding what your issues are.


Doesn't that help?

It would be good if someone who knows about introspection looked at bug #661487.
  - "Is there any particular reason not to use pygobject 3?"

(In reply to comment #42)
> I thought that issue was covered by comment 30:
> 
> > As for the raise issue shouldn't functions be namespaced?  I would recommend
> > never using * to import symbols in gi.
> > 
> > from gi.repository import GooCanvas
> > 
> > GooCanvas.raise(...)
> > 
> > ^---that should avoid any namespace clashes with Python builtins and keywords
> > though I might not be completely understanding what your issues are.
> 
> 
> Doesn't that help?

Nope, i responded, it's already what i did but didn't work. A suggestion would be to rename raise to raise_ like in pygoocanvas.

Sorry, I missed that comment.

For now you could write your own raise function in python - it is a pretty simple function in C.

Does anyone know how to rename the function in python?

(In reply to comment #45)
> Sorry, I missed that comment.
> 
> For now you could write your own raise function in python - it is a pretty
> simple function in C.
> 
> Does anyone know how to rename the function in python?

Im to busy to finish this at the moment. Does the 'Rename to: raise_' annotation work?

(In reply to comment #43)
> It would be good if someone who knows about introspection looked at bug
> #661487.
>   - "Is there any particular reason not to use pygobject 3?"

Makes sense.

(In reply to comment #46)
> (In reply to comment #45)
> > Sorry, I missed that comment.
> > 
> > For now you could write your own raise function in python - it is a pretty
> > simple function in C.
> > 
> > Does anyone know how to rename the function in python?
> 
> Im to busy to finish this at the moment. Does the 'Rename to: raise_'
> annotation work?

Did you plan to commit this work soon ?

A rename should'nt take long to do, no ? (i'm a total novice with gobject introspection annotation)

Any progress on this ?

(In reply to comment #49)
> Any progress on this ?

I'm not working on this anymore.

I still don't know enough about introspection & python to do it.

I also worry that if we use the "rename" annotation now, we break
all the other languages that have been using "raise" already.

The "raise" issue seems to have been fixed in Pygobject 3.3.3:

http://www.piware.de/2012/06/pygobject-3-3-3-released/

That's good. I guess we can close this bug now.

Though there are still a few minor introspection problems - see bug 677013.

I'm closing this now. Feel free to open new bugs if there are remaining issues.