This should fix the issue mentioned here: http://forums.scummvm.org/viewtopic.php?t=11255
Apparently Windows doesn't generate unique names for MIDI devices of the exact same type.
I do not know whether this could be a problem on other backends, too.
Because the "clear" buttons are very different between themes (in
the Modern theme they have a graphical symbol, while in the Classic
theme they have a letter), they have to be removed and re-added
when reflowing the layout. This is patterned after how the
LauncherDialog class handles the larger changes in layout.
Removing widgets from a tab turned out to be trickier than I first
thought, so I had to move the removeWidget() method from Dialog to
GuiObject.
KYRA 1 PC-98 supports both modes in the same target. The desired mode can now be selected in the rendering options. We did have good support for the 16 colors mode of KYRA 1 already. This mode could not really be selected though (except by manually modifying the config file or the code).
Currently, the usages associated with savegames have been omitted.
These will probably need a different prefix constant as it is likely
foreign variants still use "DREAMWEB.*" for savegames, while using
a different prefix for the datafiles. We may even migrate away from
this naming convention as this causes savegame collisions when multiple
language variants are present, which could cause issues.
The usages in the Room members of the constant g_roomData structure have
also been omitted, as the members are copied into the savegame format,
thus replacing these and fixing other accesses is not trivial.
This new variable removes the need for duplicates strings of the form
"DREAMWEB.*" spread throughout the dreamweb engine, replacing them with
a common const string on the engine holding the datafile name prefix.
This will reduce binary size and it should also simplify adding support
for foreign language variants, where the datafile name prefix is
changed.
To demostrate usage and prove this, showPCX() is migrated to using this.
This allows for better sharing between the current video state in the view and
the OSystem implementation.
This also gets rid of most C interface functions for calling ObjC code.
