Re: [hatari-devel] Hatari UI, Python & Gtk, v2 vs v3

[David Savinkoff <dsavnkff@xxxxxxxxx>]

On Thursday 05 January 2012 12:38, Eero Tamminen wrote:
> Hi,
>
> On tiistai 03 tammikuu 2012, David Savinkoff wrote:
> > In the process of making this package for my old system I discovered
> > some issues with hatari-ui.
> >
> > hatari-1.6.0.py2.4.patch removes 'as' from Python 2.4 code.
>
> Hm.  "Except ... as ...:" syntax seems to be introduced in Python v2.6.
>
> Your patch should use "," instead of "as" for the older versions:
> http://stackoverflow.com/questions/2535760/python-try-except-comma-vs-as-in
>- except
>
> Otherwise you lose information.  But I don't know whether it's Python v3
> compatible[1].

Thanks. I used the context of the code to modify the code since I've
never touched Python... it worked!

>
> > hatari-1.6.0.gtk2.10.patch reverts Gtk v2.12 to the deprecated Gtk v2.10
> > tooltip API for Compatibility because Gtk v2.24 is the Last version and
> > deprecation is now Meaningless.
>
> Latest Gtk version is actually 3.2.x.  I guess you meant that PyGtk
> supports only Gtk v2.x.

See "PyGTK-2.24 will be the final major release of PyGTK.":
http://mail.gnome.org/archives/gnome-announce-list/2011-April/msg00002.html

I don't believe 2.24 is necessarily the best version as it was being designed
to bridge into Version 3. (Gnome 3 ?)

What really matters is what features you want to use in hatari-ui.

>
> [1] I removed the deprecated Gtk v2.x API usage before Hatari v1.5 release
> because Hatari Fedora package maintainer asked me to make Hatari's Python
> scripts Python v3 compatible.
>
> Anything wanting to support Python3 and Gtk3 (i.e. not drag Python2 and
> Gtk 2.x stuff in) needs first to remove all references to deprecated Gtk
> 2.x APIs and then port the code to PyGObject v3:
> 	http://developer.gnome.org/gtk3/3.3/gtk-migrating-2-to-3.html
> 	http://live.gnome.org/PyGObject/IntrospectionPorting
>
>
> When I started this transition, I still thought that one could continue
> using PyGtk and have it somehow backwards compatible, like the rest of
> the Hatari Python scripts (already) are.  Unfortunately that's not the
> case, so I've post-poned finnalizing this transition until Gtk3 and
> corresponding PyGtk replacement are widely[1] available.
>
>
> [1] They will be in next Ubuntu and Debian stable versions:
> 	http://packages.ubuntu.com/precise/python3-gi
> 	http://packages.ubuntu.com/precise/gir1.2-gtk-3.0
> 	http://packages.debian.org/wheezy/python3-gi
> 	http://packages.debian.org/wheezy/gir1.2-gtk-3.0
>
> Both Fedora 16 and OpenSUSE v12.1 (released a while ago) already
> support pygobject3.

Fedora is always experimental.  RHEL 6 is a much better choice.
Redhat is very good at supporting old binaries. I can run code
'compiled on a 486 with decades-old RH 6.2' on 'PIII CentOS 5'.

> And next LSB, Linux Standards Base v5.0 is planning on deprecating
> at least Gtk v2, maybe also Python v2, and have v3.
>
> > CentOS 5 needs these patches to work,
> > CentOS 6 doesn't. I tested these patches on CentOS 5, I don't have
> > CentOS 6. Please consider these patches for Hatari.
>
> Does this make sense anymore?

RHEL 6 and CentOS 6 make good sense (New). I believe hatari-ui will be
fine on RHEL 6 as long as Hatari supports python 2.6.6 and gtk 2.18.9

RHEL 5 = gtk 2.10.4  pygtk 2.10.4   python 2.4.3

What versions of python and gtk do you think are the most future-proof
in 'deprecated' form?
Maybe it is a good idea to tag old versions of hatari-ui?
What code features does hatari-ui need?

> If you had sent this before Hatari v1.5 release or even before v1.6, it
> would be clearer, but those releases were already with the new tooltips
> API.

Tool tips work with my patches.

> Next Hatari Python UI may already be Python3 / Gtk3 / PyGObject based,
> depending a bit on when it will come out.  I would assume Hatari v1.8
> at least to be so.
>
>
> 	- Eero

I brought this subject so that Hatari could have long-term maintenance-
free code. It would be nice to simply compile a 30 year old tarball.

 David