"gvba" does not write the battery file until the game is closed

[vocx]

Binary package hint: visualboyadvance

Ubuntu 9.04
visualboyadvance: 1.8.0-4ubuntu1
visualboyadvance-gtk: 1.8.0-4ubuntu1
vbaexpress: 1.2-0ubuntu3

This bug report concerns Battery files, those ending with ".sav"
It is not about Save states, those ending with ".sgm"

General description:
When run from the GTK+ interface (gvba), VisualBoyAdvance doesn't create a battery file ".sav", until you close the game, or exit the application. This behavior is different from that observed by running "VisualBoyAdvance" or "vba" directly from the command line, or using the "vbaexpress" interface, which uses the FL toolkit (FLTK).

Run a game from the command line (this calls a bare SDL interface)
    vba game.zip

In a few seconds the message "Battery wrote" appears, and a battery file is created
    $HOME/.vba/game.sav

The same happens by running
    vbaexpress

and loading the game through the interface, File > Open a Game...

Whenever the words "Battery wrote" appear on the screen, either automatically or because you reached a save point within the game, the battery file is created or updated, if it already existed. This can be seen by keeping the file manager open during the save.

If you use the GTK+ interface
    gvba game.zip

you can play for hours, but the "Battery wrote" message never appears. If you select File > Close, or File > Exit, the game ends, and the battery file is created or updated immediately after. Again, this can be seen by keeping the file manager open in the directory where the batteries are saved.

This obviously presents a problem, because if "gvba" doesn't exit cleanly, or you reset the game within the emulator, the battery file is never created or updated properly.

Since "VisualBoyAdvance" works correctly with the bare-bones SDL interface, I suspect the problem lies with its interaction with the GTK+ interface, which uses Glade. It actually uses GTKmm and libglademm, since it is in C++.

The "vbaexpress" interface overcomes these problems because apparently it only sets-up the configuration file "VisualBoyAdvance.cfg", and then forks the "vba" process, and thus the FLTK toolkit does not interact with the SDL window.

[Nick Ellery (nick.ellery)]

According to upstream, this is the desired behavior. Closing bug.

[vocx (eliudcabrera)]

Can I at least get an explanation as to why that is the desired behavior?
Are there any links to a discussion upstream?

As I tried to explain, the essential problem is that "gvba" doesn't save the game batteries when it should:
    if "gvba" doesn't exit cleanly, or you reset the game
    within the emulator, the battery file is never created
    or updated properly.

I find this to be a usability problem, with potential for data loss.

Think about a word processor analogy, I expect my document to be saved at the instant I click the button that says "save", not when I close the entire office application.