Re: [pygtk] Turning the PyGTK+ brand into something more than it currently is



Hi Jasper,

On Thu, 15 Nov 2012 16:25:32 -0500
"Jasper St. Pierre" <jstpierre mecheye net> wrote:
> I like Python. I help new people out in Python IRC channels, on forums,
> and I recommend Python to friends and family who say they want to learn
> programming.
> 
> At some point, the time comes when they want to start doing fancy
> graphical GUI stuff. And after a little bit of research, they come to a
> dilemma: "should I use PyGTK+ or PyQt?"
> 
> They don't know that PyGTK+ is dead, or if they somehow found that out,
> they don't realize that there's a better replacement right around the
> corner. http://www.pygtk.org/ is still around, but it looks like it
> hasn't been updated since 1998, given the retro scanline effect on the
> header. It of course also doesn't help that the last notable news event
> was reported on April Fools.
> 
> Sometimes they've heard of this "PyGObject", but they conclude it's a
> low-level plumbing layer.
> 
> The PyGTK+ reference docs come up a lot when Googling for them;
> obviously, our better documentation solution actually based on
> introspection information isn't ready yet, but I wonder if there's some
> minor tweaks we can make to make the solution suck less there.
> 
> I think we could do a lot more with the PyGTK+ name and
> http://www.pygtk.org/ to promote gobject-introspection as our new,
> exciting solution. If nothing else, it rolls off the tongue much easier.
> Say it a few times.
> 
> Anybody have any other ideas here?

Unless I'm mistaken (and I hope I am), there is a fundamental problem
with PyGObject that PyQt doesn't have.

With PyQt you can get binary installers for Windows for any PyQt X
Python 2 or 3 combination you want: this is really helpful for
deployment.

And for development, you can easily build any combination of PyQt X Qt X
Python 2 or 3 on Mac and Linux, just by downloading an tarball and doing
a really easy configure and build.

But I personally have found it impossible to build PyGObject at all, let
alone build it for multiple Python versions. This may of course be due
to my own failings, but the fact is, it is _easy_ to build PyQt with any
Python you want (on Unix). I haven't tried building PyGObject for about
6 months, so I really hope I'm out of date. But IMO, being able to to
build PyGObject X Python 2 and 3 versions is essential for being able to
test and deploy your code confident that that it will work correctly on
a wide range of systems.

I think that the whole introspection approach is really excellent
(*much* better than the ad hoc approach taken with Qt), since it allows
people to use Gtk+ with their preferred language, so I hope that the
infrastructure for it improves---and that it becomes a genuine
cross-platform alternative to PyQt.

-- 
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
    C++, Python, Qt, PyQt - training and consultancy
        "Advanced Qt Programming" - ISBN 0321635906
            http://www.qtrac.eu/aqpbook.html


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]