Re: What is the significance of pygtk.require('2.0')?

[John Palmieri <johnp redhat com>]

----- "Robert Park" <rbpark exolucere ca> wrote:

> Hi J5!
> 
> On Thu, Oct 28, 2010 at 4:15 PM, John Palmieri <johnp redhat com>
> wrote:
> > We still have to support it because pygi will only be for Gtk 3.0
> and so there will be a lot of legacy code running around.
> 
> This is news to me. I thought I was developing for Gtk2 with these GI
> bindings. So Gtk2 will be dropped once Gtk3 is finalized?

It is really hard to support Gtk 2 in GI since there is a lot of arbitrary C code that can't be wrapped.  We aren't dropping Gtk 2 per se.  The plan is to keep PyGtk working for Gtk 2 and have PyGI focus on Gtk 3.  You can sort of use it for Gtk 2 but things like style structures will not work and there is just a lot of API that isn't annotated correctly.  Here is the support matrix:

Gtk2 -> Python 2 -> PyGTK (maintenance mode mostly)
Gtk3 -> Python 3 -> PyGI (though Python 2 support has been easy to maintain and I'm really the only person developing on Python 3 as of now)

> > As for you needing to add them to new code, I don't think it is
> necessary though it may be on some systems.
> 
> Ok, so I can safely remove that from my program? It's only for legacy
> code?

I can give you a big equivocal "I'm not sure".  My whole writeup was just working out what could go wrong and why we haven't gotten rid of it.  It really is a bunch of voodoo we inherited and I would like to remove it, but only if I am 100% sure we will not break apps.  To tell you the truth I never actually imported them though I do notice that sometimes when I am installing to alternate directories for testing, things go wrong.  My advice is you can remove it but keep in mind, if someone complains they can't run your app that might be the cause.

> >  In any case paths are important to keep consistent for legacy
> support since it is hard to know what will break if you move things
> around.  If we can emulate the old paths while moving the modules out
> then I say we do it.
> 
> Oh, I'm all for legacy support, but that's not really what I'm
> asking.
> I don't personally care what path pygi is installed to. My question
> is, what specific purpose does "pygtk.require('2.0')" serve when the
> pygtk module is not ever referenced afterwards? Can I safely remove
> this from my program without breaking anything?

Ignore the fact that the module is called pygtk.  That is just an effect of the directory it is installed into.  The code mostly just sets a few global variables that other code then references (and also sets up paths).  I'll have to look at it in depth.   

> From my casual understanding, it seems to me that I'm importing the
> old static bindings, telling them to require some version of
> something
> or other, and then never using them in favor of using the
> introspection bindings afterwards. I guess the root of the issue here
> is that I am very confused about the meanings of the terms "pygtk",
> "pygi", and "pygobject" and how they relate. I _thought_ that "pygtk"
> meant "old, static bindings, crufty, unsupported, don't use anymore"
> and "pygi/pygobject" meant "new, introspection, sexy, dynamic, the
> future", so I'm just not sure why I am importing the pygtk module
> _at_all_ when I am only using introspection bindings. What purpose
> does "pygtk" module serve in introspection-land?


A little more background.  Static bindings and the introspection bindings both work off the same pygobject base.  The pygtk "module" is part of that base.  It is an effect of the directory everything is installed into.  At one point there was no pygobject, only PyGtk which is why the module is named pygtk.  GObject started to be used for a lot more non-gui stuff so it was decided to split the Gtk code from the GLib/GObject code.  The directory pygtk was kept the same for pretty much the same reasons we can't come to a decision now.  It might break things ;)  So when you import pygtk you aren't actually importing anything Gtk.  You are setting up a few variables.  Either way it doesn't hurt, it just look ugly and is somewhat confusing.  But like I said, try not importing it and let us know if anyone complains.

--
John (J5) Palmieri
Software Engineer
Red Hat, Inc.