Well, I am still not used to this blogging stuff ;), so updates happen not too often, sorry.
But there is something new to see, it's e-uae WIP2 for AROS with a GTK-MUI gui:
E-uae can be built with normal configure and make (I will submit my changes to evilrich soon, promised). There are still some minor bugs left (radiobuttons are not updated with the previous saved values for example), but you can make changes to the config and start uae. You can swap disk images. And after a long bug hunt, you can now even close uae with the quit buttons ;).
This build was done with my glib 2.6.6 (now also in archives.aros-exec.org) and with GTK-MUI build from the GLIB-oli branch.
What's left for a GTK-MUI upload to archives is the merging of the two development branches, which is still to be done :(.
So, what can you do with GLib/GTK-MUI at the moment?
(this is quoted from my mail to teamaros)
GTK-MUI(zune) is based on top of GLib (not necessarly on my GLib port,
it should work with every GLib port for example on AOS4/morphOS).
GTK-MUI offers a lot of GtkWidgets(but far from all), which
are more or less complete compatible with their real GtkWidgets.
So if your GTK app uses only existing GTK-MUI widgets (and only
implemented methods of those widgets) it should be a simple job
to port the app. In that ideal case it might be enough to run
configure and make ;).
The real world looks different, as there are a hell lot of
GtkWidgets and every widget has a hell lot of methods ;).
In GTK-MUI, MUI (zune) does more or less the job of GDK, it
renders the gadgets and sends the signals. So not many GDK funtions
are implemented at the moment. If you app relies a lot on GDK,
it will get difficult. Also pango (the GTK text rendering engine)
is still missing completely. Might be the next big step to
port that, not impossible to do it the GLib way. Freetype
lib should be available on AROS, as far as I have seen, but
pango also requires fontconfig, this is not on AROS or am I
wrong?
Custom GtkWidgets (equivalent to private custom classes in
Zune) do work in GTK-MUI, the less they depend on GDK, the
better;).
But there is something new to see, it's e-uae WIP2 for AROS with a GTK-MUI gui:
E-uae can be built with normal configure and make (I will submit my changes to evilrich soon, promised). There are still some minor bugs left (radiobuttons are not updated with the previous saved values for example), but you can make changes to the config and start uae. You can swap disk images. And after a long bug hunt, you can now even close uae with the quit buttons ;).
This build was done with my glib 2.6.6 (now also in archives.aros-exec.org) and with GTK-MUI build from the GLIB-oli branch.
What's left for a GTK-MUI upload to archives is the merging of the two development branches, which is still to be done :(.
So, what can you do with GLib/GTK-MUI at the moment?
(this is quoted from my mail to teamaros)
GTK-MUI(zune) is based on top of GLib (not necessarly on my GLib port,
it should work with every GLib port for example on AOS4/morphOS).
GTK-MUI offers a lot of GtkWidgets(but far from all), which
are more or less complete compatible with their real GtkWidgets.
So if your GTK app uses only existing GTK-MUI widgets (and only
implemented methods of those widgets) it should be a simple job
to port the app. In that ideal case it might be enough to run
configure and make ;).
The real world looks different, as there are a hell lot of
GtkWidgets and every widget has a hell lot of methods ;).
In GTK-MUI, MUI (zune) does more or less the job of GDK, it
renders the gadgets and sends the signals. So not many GDK funtions
are implemented at the moment. If you app relies a lot on GDK,
it will get difficult. Also pango (the GTK text rendering engine)
is still missing completely. Might be the next big step to
port that, not impossible to do it the GLib way. Freetype
lib should be available on AROS, as far as I have seen, but
pango also requires fontconfig, this is not on AROS or am I
wrong?
Custom GtkWidgets (equivalent to private custom classes in
Zune) do work in GTK-MUI, the less they depend on GDK, the
better;).