wxPython on GTK

[Batista, Facundo]

I'm still deciding about using Tkinter or wxPython for a project I have
(sigefi, on SF).

The decision is not made, I have to finish first a little program that will
be done in both GUIs, and then make a choice (I'll write something about the
experiment, I'll let you know).

In this context, I got worried when a friend of mine (codeveloper of sigefi)
could not install PyNSource because wxPythonGTK been always using private
methods from GTK, and now that GTK does not have them anymore, don't work.

The bug is 915333
(http://sourceforge.net/tracker/index...33&group_id=98
63&atid=109863).

The problem is that it's actually closed but not fixed, so I'm worried about
the viability of wxPython in GTK.

Do you know something about this?

Thank you!

.. Facundo

[Fernando Perez]

Batista, Facundo wrote:

In this context, I got worried when a friend of mine (codeveloper of sigefi)
could not install PyNSource because wxPythonGTK been always using private
methods from GTK, and now that GTK does not have them anymore, don't work.

The bug is 915333
(http://sourceforge.net/tracker/index...33&group_id=98
63&atid=109863).

The problem is that it's actually closed but not fixed, so I'm worried about
the viability of wxPython in GTK.

My _guess_ is they'll have to fix it, and sooner rather than later. Wx is in
widespread use under Linux, and they managed to break it completely under
(among others) Fedora Core 2:

In [2]: import wx
---------------------------------------------------------------------------
ImportError Traceback (most recent call last)

/home/fperez/code/python/vis3d/<console>

/usr/lib/python2.3/site-packages/wx/__init__.py
43 __revision__ = "$Revision: 1.1.2.4 $"[11:-2]
44
---> 45 from wxPython import wx
46
47 _newnames = {}

/usr/lib/python2.3/site-packages/wxPython/__init__.py
18 # Ensure the main extension module is loaded, in case the add-on
modules
19 # (such as utils,) are used standalone.
---> 20 import wxc
21
22
#----------------------------------------------------------------------------

ImportError: /usr/lib/libwx_gtk2-2.4.so.0: undefined symbol:
_gtk_accel_group_detach

Essentially in Fedora2, Wx is unusable.

I honestly doubt they can leave such a catastrophic bug alive for long, they'd
shoot themselves in the foot by losing all users, as linux distros migrate
over to current GTK.

So I suspect public pressure will help fix this soon, though I honestly wish it
hadn't happened in the first place (I've lost the usage of some code which
relied on wx).

Cheers,

f

[David Fraser]

Fernando Perez wrote:

Batista, Facundo wrote:

In this context, I got worried when a friend of mine (codeveloper of sigefi)
could not install PyNSource because wxPythonGTK been always using private
methods from GTK, and now that GTK does not have them anymore, don't work.

The bug is 915333
(http://sourceforge.net/tracker/index...33&group_id=98
63&atid=109863).

The problem is that it's actually closed but not fixed, so I'm worried about
the viability of wxPython in GTK.

My _guess_ is they'll have to fix it, and sooner rather than later. Wx is in
widespread use under Linux, and they managed to break it completely under
(among others) Fedora Core 2:

In [2]: import wx
---------------------------------------------------------------------------
ImportError Traceback (most recent call last)

/home/fperez/code/python/vis3d/<console>

/usr/lib/python2.3/site-packages/wx/__init__.py
43 __revision__ = "$Revision: 1.1.2.4 $"[11:-2]
44
---> 45 from wxPython import wx
46
47 _newnames = {}

/usr/lib/python2.3/site-packages/wxPython/__init__.py
18 # Ensure the main extension module is loaded, in case the add-on
modules
19 # (such as utils,) are used standalone.
---> 20 import wxc
21
22
#----------------------------------------------------------------------------

ImportError: /usr/lib/libwx_gtk2-2.4.so.0: undefined symbol:
_gtk_accel_group_detach

Essentially in Fedora2, Wx is unusable.

I have four versions of wxPython running successfully on Fedora 2 - wx
2.4.2.4 with GTK, wx 2.5.1.5 with GTK, wx 2.5.1.5 with GTK2 and wx 2.5.2
prerelease with GTK2

The only problem is that certain binary RPMs produced aren't compatible
with Fedora Core 2, because they're built on a RedHat 9 machine

You can rebuild them from source rpms and they work fine. In fact
(checks) ... surprise, surprise, you can get Fedora RPMs from Fedora extras.

Now if you have a problem with that you can complain :-)

David

[David Fraser]

Batista, Facundo wrote:

I'm still deciding about using Tkinter or wxPython for a project I have
(sigefi, on SF).

The decision is not made, I have to finish first a little program that will
be done in both GUIs, and then make a choice (I'll write something about the
experiment, I'll let you know).

In this context, I got worried when a friend of mine (codeveloper of sigefi)
could not install PyNSource because wxPythonGTK been always using private
methods from GTK, and now that GTK does not have them anymore, don't work.

The bug is 915333
(http://sourceforge.net/tracker/index...33&group_id=98
63&atid=109863).

The problem is that it's actually closed but not fixed, so I'm worried about
the viability of wxPython in GTK.

Do you know something about this?

Thank you!

. Facundo

I wouldn't worry about this - I have compiled the development releases
of wxPythonGTK2 without a problem.
I reckon wxPython is probably the most viable solution for sigefi... By
the time sigefi gets anywhere near release wxPython 2.6 should be out

David

[C Johnson]

Fernando Perez <fp*******@yahoo.com> wrote in message news:<cb**********@peabody.colorado.edu>...

Batista, Facundo wrote:
--8<--SNIP--8<--

The problem is that it's actually closed but not fixed, so I'm worried about
the viability of wxPython in GTK.

That may be the result of wxWidgets core library never stating support
of GTK+2.4 up. (More following this)

--8<--SNIP--8<-- I honestly doubt they can leave such a catastrophic bug alive for long, they'd
shoot themselves in the foot by losing all users, as linux distros migrate
over to current GTK.

I am unsure who "they" are in this context but wxWidgets, wxGTK in
particular has *EXPERIMENTAL* support for GTK+2.2 and is of course
suppose to fully support GTK+1.2 up. Nowhere in the documentation of
the wxWidgets code base does it state support for GTK+2.4 up. Like
you I can only hope they are working on it but in the mean time I am
trying to come up to speed with the GTK+ core API so that I can submit
patches around the "accidentally exported" public symbols from GTK+2.2
that wxGTK-2.4.2 has been using. Technically speaking, no - none of
the offending code base *should* have worked if it weren't for
accidentally exported symbols/API change on the GTK+ side that the
wxGTK side picked up.
So I suspect public pressure will help fix this soon, though I honestly wish it
hadn't happened in the first place (I've lost the usage of some code which
relied on wx).

I am not a core wxWidgets developer* but in the event that they are
not, which I doubt they are *not* going to address, others are - I
surely am not the only one stepping up here. ;) I am starting to
learn python from a C++ background so that is the motivation for
disrupting your group as well as encountering this problem too.

Chris
linuxok71 AT itlnet DOT net

*I am in no way affiliated with the wxWidgets/wxGTK/GTK core
development team(s) or a spokesperson for them. If in doubt about the
information in my post then you would be wise to disregard it. This
is information that I, as an individual, have gathered over the last
three days of "discovering" this issue. Any errors are quiet honestly
a mistake and not malicious in nature.

[Fernando Perez]

David Fraser wrote:

Fernando Perez wrote:

ImportError: /usr/lib/libwx_gtk2-2.4.so.0: undefined symbol:
_gtk_accel_group_detach

Essentially in Fedora2, Wx is unusable.

I have four versions of wxPython running successfully on Fedora 2 - wx
2.4.2.4 with GTK, wx 2.5.1.5 with GTK, wx 2.5.1.5 with GTK2 and wx 2.5.2
prerelease with GTK2

The only problem is that certain binary RPMs produced aren't compatible
with Fedora Core 2, because they're built on a RedHat 9 machine

You can rebuild them from source rpms and they work fine. In fact
(checks) ... surprise, surprise, you can get Fedora RPMs from Fedora extras.

Now if you have a problem with that you can complain :-)

I should have qualified that with 'out of the box Fedora 2', since the WX
included in the official install doesn't even import at all. This kind of
pissed me off (at Fedora, for shoddy testing), that they'd ship a fairly used
library which can't even be _started_ (meaning, 'import wx' failing).

It annoyed me b/c for deployment on multiple systems, being forced to track
separate builds from multiple repositories is just a recipe for headaches.

But this is not a thread on all the _other_ things that don't work at all with
FC2, so let's just not get started :)

I didn't mean to disparage the WX team. I'll just patiently wait for things to
catch up.

Cheers,

f

[David Fraser]

C Johnson wrote:

Fernando Perez <fp*******@yahoo.com> wrote in message news:<cb**********@peabody.colorado.edu>...

Batista, Facundo wrote:

--8<--SNIP--8<--

The problem is that it's actually closed but not fixed, so I'm worried about
the viability of wxPython in GTK.

That may be the result of wxWidgets core library never stating support
of GTK+2.4 up. (More following this)

--8<--SNIP--8<--

I honestly doubt they can leave such a catastrophic bug alive for long, they'd
shoot themselves in the foot by losing all users, as linux distros migrate
over to current GTK.

I am unsure who "they" are in this context but wxWidgets, wxGTK in
particular has *EXPERIMENTAL* support for GTK+2.2 and is of course
suppose to fully support GTK+1.2 up. Nowhere in the documentation of
the wxWidgets code base does it state support for GTK+2.4 up. Like
you I can only hope they are working on it but in the mean time I am
trying to come up to speed with the GTK+ core API so that I can submit
patches around the "accidentally exported" public symbols from GTK+2.2
that wxGTK-2.4.2 has been using. Technically speaking, no - none of
the offending code base *should* have worked if it weren't for
accidentally exported symbols/API change on the GTK+ side that the
wxGTK side picked up.

So I suspect public pressure will help fix this soon, though I honestly wish it
hadn't happened in the first place (I've lost the usage of some code which
relied on wx).

I am not a core wxWidgets developer* but in the event that they are
not, which I doubt they are *not* going to address, others are - I
surely am not the only one stepping up here. ;) I am starting to
learn python from a C++ background so that is the motivation for
disrupting your group as well as encountering this problem too.

Chris
linuxok71 AT itlnet DOT net

Glad to hear you are trying to sort this out. I suggest you join the
wx-dev list and report on your progress there... I think you'll find
that the core developers will be very receptive to your contributions
and helpful with questions...

David