* Changed FADE_TO_BLACK to SCREEN_FADE_OUT
* Updated the red [color_adjust] to [screen_fade]. Also tweaked the
timing to make it flow smoothly.
* Removed the now-unnecessary kill tag used to hide units before
the fade.
New macros:
* SCREEN_FADE_OUT - to replace FADE_TO_BLACK in most cases
* SCREEN_FADE_IN - to replace FADE_IN in most cases
* SCREEN_FADE r g b duration
- convenience wrapper for [screen_fade] with 255 alpha
* SCREEN_UNFADE duration
- convenience wrapper for [screen_fade] with 0 alpha
* FLASH r g b actionWML
- like FLASH_WHITE etc but takes a colour
* FLASH_LIGHTNING actionWML
- flashes an appropriate colour and plays lightning.ogg
Modified macros:
* FLASH_WHITE/RED/GREEN/BLUE}
- these now use [screen_fade] not [color_adjust]
This implements an add-on extraction progress dialog that does not
actually run its own event loop, allowing the caller to take ownership
of it (display() static method) and update its state using a callback
function object. The object in question is passed into the add-ons
management API and used to update the dialog status each time an add-on
file is written to disk as part of the pack extraction process.
In order to avoid stalling the extraction process in UI code, the
callback is invoked for every single file, but the dialog's progress
update method places a time restriction on GUI2 API calls of 120
milliseconds -- this is a good throttle interval that allows add-ons to
be extracted in about the same amount of time as before while still
updating the progress bar smoothly enough for add-ons that take longer
than that.
(This is not the most trivial code to test, so it is suggested to add a
sleep/delay API call in unarchive_file() in src/addon/manager.cpp to
introduce artificial delays.)
One issue with this code, however, is that because modeless_dialog
doesn't execute its own event loop, the only way to get the dialog to be
updated is to force a draw event in ourselves via the new
gui2::dialogs::modeless_dialog::force_redraw() method. This is really a
side-effect of my design choice here to run the dialog in the middle of
a blocking operation instead of somewhere where events are being
processed normally. I'm not entirely sure if the draw events would be
pushed even in that case, however.
Closes#1101.
Otherwise testing 55 things in a single test takes a lot longer than any other test when using the debug build, which messes with the execution script's process timeout setting.
Either it should be reused, or it should be destroyed before the game.
Previously it was being kept alive just out of view until game end,
whereupon it was destroyed and recreated.
Now it just gets destroyed before entering the game.
This would probably have fixed several other bugs if i hadn't already
made independent workarounds for them.
Windows can now be kept and hidden/shown as required. Event callbacks
should now be set in the constructor, not in pre_show(), unless they
are also disconnected in post_show().
