OtherTuningSoftware/Strategy (2005-01-01 14:04:00)

Developer info. Strategy of OtherTuningSoftware

The fact is that we don't have a good tuningsoftware at the moment. MegaTune and MegaTunix are closest, but they only support the features that are implemented in mot. megasquirt.

We need at least 2 tuningsoftware


How do we get to the C tuningsoftware?

If we can create OtherTuningSoftware/NintendoGameBoy, we should be able to easily use it (above GTK/GDK with minor porting) on notebook. If we have 2 independent C codebases for GBA and notebook in the long run, we might be doing something wrong.

But 2 independent C codebases might be the only way in the short run:

The question is if it's better to write GBA software from ground-up, or significant portion of MegaTunix can be reused.


Is it better to make GBA software from

The question boils down to the issue:

How severily does it depend on gtk/glib ? In other words, how good is the separation between business logic and GUI ? It seems that it's a bit monolithic, but I might be wrong.

Using basic classes like gpointer, ghash, etc... can be OK. But depending on gwidget for storage of essential data can be a problem.

If it depends heavily on GTK/GDK/Glib, than rewrite seems to be a better option, because OtherTuningSoftware/WidgetSet suggests GTK is a no-go.


Code to share with the GBA and desktop tuning software - should go to OtherTuningSoftware/CommonInfrastructure ?


See also