After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 626231 - Migrate from PyGTK to PyGObject introspection-based bindings
Migrate from PyGTK to PyGObject introspection-based bindings
Status: RESOLVED FIXED
Product: libchamplain
Classification: Core
Component: bindings
0.7.x
Other Linux
: Normal normal
: ---
Assigned To: libchamplain-maint
libchamplain-maint
Depends on:
Blocks: 626218
 
 
Reported: 2010-08-06 16:27 UTC by André Klapper
Modified: 2011-03-14 16:13 UTC
See Also:
GNOME target: ---
GNOME version: 2.31/2.32


Attachments
Allow introspecting of champlain_embed_get_view (463 bytes, patch)
2010-12-28 20:48 UTC, Robert Bruce Park
none Details | Review

Description André Klapper 2010-08-06 16:27:59 UTC
Grep'ing for pygtk-2.0 it seems that this module uses the stable bindings provided by PyGTK. 

As it is unlikely that anybody will continue maintaining these stable bindings, applications using PyGTK should be ported to using the dynamic Python bindings provided by PyGObject (now that PyGI has been merged into PyGObject).
The feedback on migration provided by application maintainers will also help PyGObject to improve its dynamic bindings.

Please see http://live.gnome.org/GnomeGoals/PythonIntrospectionPorting for more information and guidelines.

For help there is a mailing list at http://www.daa.com.au/mailman/listinfo/pygtk . For getting involved in the development of pygobject there is a mailing list at http://mail.gnome.org/mailman/listinfo/python-hackers-list . There is also the #python IRC channel on irc.gimp.net.

./libchamplain/configure.ac:      pygtk-2.0 >= 2.12
Comment 1 Jiri Techet 2010-08-09 19:35:52 UTC
What's the current status of PyGI? Is it "production ready" or rather experimental so far? If the latter holds won't there be any transition period in which both PyGTK and PyGI will be supported? In what time period are applications using PyGTK supposed to be migrated to PyGI?
Comment 2 André Klapper 2010-08-09 19:44:07 UTC
Ahoj Jiri,

> What's the current status of PyGI? Is it "production ready" or rather
> experimental so far?

Better you ask on the python-hackers mailing list as I'm not a Python hacker...

> any transition period in which both PyGTK and PyGI will be supported? 

PyGTK has not seen any changes for quite a while now hence I would rather call it dead than supported. And there is not enough manpower to "support" both.

> In what time period are applications using PyGTK supposed to be migrated 
> to PyGI?

The sooner the better, as feedback and porting issues would help the GNOME Python team to improve PyGI in PyGObject...? :)
Comment 3 André Klapper 2010-08-09 19:49:44 UTC
...and just when writing this I see that there is a new unstable 2.21 tarball for pygtk (but 2.22 will be the last release of PyGTK according to the wiki).
Comment 4 Jiri Techet 2010-08-09 21:09:44 UTC
OK, thanks for the info, I was just curious about the current PyGI status. Our python bindings maintainer is Victor Godoy Poluceno so I actually hope it won't be me who has to make the changes ;-).
Comment 5 Robert Bruce Park 2010-12-28 20:48:27 UTC
Created attachment 177161 [details] [review]
Allow introspecting of champlain_embed_get_view
Comment 6 Jiri Techet 2011-01-01 16:47:08 UTC
Robert, are you sure about the (transfer full)? In my opinion there should be (transfer none) because GtkChamplainEmbed is still the owner of the view.

I've added --warn-all flag to the scanner and added transfers to all the necessary functions to eliminate the warnings.
Comment 7 Robert Bruce Park 2011-01-02 01:26:28 UTC
I'm not at all sure. It was simply a guess based on reading GtkChamplain-0.6.gir (which I knew to work), which contained this:

      <method name="get_view"
              c:identifier="gtk_champlain_embed_get_view"
              version="0.4">
        <doc xml:whitespace="preserve">Gets a #ChamplainView from the #GtkChamplainEmbed object.</doc>
        <return-value transfer-ownership="full">
          <doc xml:whitespace="preserve">a #ChamplainView ready to be used</doc>
          <type name="Champlain.View" c:type="ChamplainView*"/>
        </return-value>
      </method>

The application was functional when I did it my way, but it's also functional your way, so I don't understand the distinction. 

Either way, problem solved. Feel free to close this bug ;-)
Comment 8 Tomeu Vizoso 2011-01-12 14:23:47 UTC
(In reply to comment #6)
> Robert, are you sure about the (transfer full)? In my opinion there should be
> (transfer none) because GtkChamplainEmbed is still the owner of the view.

If gtk_champlain_embed_get_view doesn't increase the refcount so the caller needs to unref it after use, then it should be (transfer none). See http://live.gnome.org/GObjectIntrospection/Annotations
Comment 9 Laurent Bigonville 2011-03-14 16:08:17 UTC
This bug can be closed too I guess