They always take in U32 strings now.
- Revert tts descriptions to string, they don't use translations, so better to keep it as strings.
- Make read() take in const U32 references.
This commit also includes some additional major changes.
- Return U32String from TransMan getTranslation()
- Change tooltips to be U32Strings
- Remove temporary code of convertToU32String
- U32 Support various dialogs (Browser, FileBrowser, Messages, Chooser, etc)
- U32 for music plugins
- U32 for OSD messages
- Add some helper functions to ustr.cpp
- Change default tooltips from nullptr & 0 -> ""
- Some runtime exceptions may occur when changing languages due to incorrect String::Format
Drawing nows happens directly when the Dialog or Widget draw methods are
called. This makes it easy to debug why a particular low level draw
method was called, by inspecting the call stack.
This replaces the notion of "buffering" by two independant ways to
control what is drawn and where:
- The active layer is used to select whether the foreground or
background part of the dialogs are rendered by the draw calls.
- The active surface is used to select if the draw calls affect the back
buffer or the screen.
The foreground layer of the active dialog is drawn directly to the
screen. Its background layer is drawn to the back buffer. This way
widgets can restore the back buffer in order to update without having to
redraw the dialog's background.
Dialogs lower in the dialog stack are drawn entirely to the back buffer.
The tooltip isn't really interested in any keyboard and mouse
events, other than as a signal to close itself, so pass them back
to the parent dialog. From what I understand, the tooltip isn't
part of the dialog, so there should be no risk of going into an
infinite loop here.
Formerly there was much special handling for the Tooltip dialog in
GuiManager::runLoop. This was replaced by overloading the event handling
functions in Tooltip. Also the Tooltip was adapted to be run like every
other normal dialog.
svn-id: r54337
Before, it could be instantiated after an engine loaded and then was never deleted, causing memory fragmentation. Also removed inner tooltip call to the GuiManager runloop, which makes the logic simpler since the tooltip is a bit of a hack. I had to remove it because deleting _tooltip in the inner loop (called from tooltip itself) is trouble.
svn-id: r54311
With help of Tanoku tooltips were switched from widgets to dialogs
which helped to fix nasty bug with background not being restored.
Although it is basically a hack around inconsistent font backbuffering
in our GUI code, for the time being it is feasible.
The patch was extended with way to specify tooltip background in the
theme file.
svn-id: r51217
