| Re: [hatari-devel] Hatari UI, Python & Gtk, v2 vs v3 |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On perjantai 06 tammikuu 2012, David Savinkoff wrote:
> > 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'.
It seems that RHEL 6 doesn't support v3 of these.
SUSE Linux Enterprise doesn't either, but I think next version
of that (supporting v3 versions) comes this year (similarly to
Debian and Ubuntu) as SLED 11 was released in 2009. I.e. it
could be there by the time Hatari v1.7 goes out.
Then everything else except for RHEL/CentOS would support
gtk & python v3.
>> Does this make sense anymore?
It seems that there needs to be fix version of Hatari v1.6 due to
the monochrome TOS bootup issue. So your patches could be considered
for the v1.6.1 branch if you update & test the exception handling one.
Have you tested that the other python code:
* rest of Hatari UI
* hconsole example.py
* stuff in atari-hd-image.sh
work also with CentOS v5?
> 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
For the Hatari head, I just corrected the version requirements.
> 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 one doesn't want to pull in Gtk v2 and python v2 on all the Linux
distros which have already migrated to Gtk v3 and (mostly[1]) to python v3,
one needs to drop use of all deprecated Gtk features and switch from pygtk
to pygobject v3.
[1] There are quite a few PyGtk applications around and I think porting
them from pygtk2 to pygobject3 is larger change than porting C programs
from Gtk v2 to v3.
If I had more time, I would consider rewriting python UI in Vala[2] with
Gtk v3. Release tarballs would then contain the pre-generated C-code in
addition to Vala code, this should make porting the UI to OSX and Windows
much simpler.
[2] http://live.gnome.org/Vala/About
> 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.
30 year old tarball? Right, about first tar implementation was in 1982. :)
That code could be K&R C-code with 16-bit ints for proprietary unixes.
If it used only standard C functions, you might be able to build it
on a modern C-compiler after fixing a lot of errors and issues related
to 16-bit ints, signedness and other peculiarities related to early
compilers.
Or the code could be BASIC (with line numbers and no functions) or assembly
code for 8-bit home computers like C64 (which was published in 1982).
That you could build/run only in emulator.
20 years old C-code using only standard C functions you might be able
just to "simply" compile, but I'm not sure what use even such thing
would be. Either it's too simple to be useful, or it has HW etc deps
you don't have except inside an emulator.
10 years old code may still be usable and feasible to build, but if it
uses stuff outside the standard C functions, you may need to re-build
all the dependencies also. If it uses something else than Make (e.g.
Autotools), you may need to get/rebuild old versions of the build tools
too.
UI code starts to be pretty hopeless case for this. If UI lib isn't nearly
dead, it changes too much / often and has a lot of build deps for 10 years
to be even desirable goal.
Something like Hatari UI needs:
- CMake and SDL v1.2.10 or newer devel files to rebuild Hatari
(as Hatari UI is somewhat tied to specific Hatari version features)
- Compatible enough Python and Gtk python bindings, those cannot
be too old because then they would hinder modern Linux distros
- Eero