OSystem now just returns a nullptr if there is no text to speech manager instance
(because none is compiled into the binary, or the system doesn't provide support
for it). This removed the need for the engine authors to add scummvm osystem compile
time options checks into their engine code
Up until last commit, everything was working fine but the amount of files changed was too large. This commit tries to reduce the changes.
- Add a fake constructor to Keymap, text-to-speech, setDescription (save-state)
- Redirecting functions for PopUpWidget::appendEntry, ButtonWidget::setLabel, GUIErrorMessage
- Use the above functions and constructors to reduce changes in Engines
- Fix warnings being in unicode. Only output english text in - Warnings, Errors, etc.
- Mark some strings as "translation" strings. (Not yet added to POTFILES)
- Remove some CP related things from po/modules.mk
- Previously used some Common::convertToU32 where it was not necessary, replace this with u32constructor
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.
Only for strings without an explicit action. The first level takes in a u32 string, encodes it, and passes it along further with the default action
- For gui widgets, the strings are passed in as native u32 strings.
- For everything else, they are being converted to u32 by Common::convertToU32... and then being passed along
- Remove convertFromU32.. where necessary
- Replace convertFromU32 to .encode() for better readability
- Fix spacing issues in tabs
- Fix spacing issues in popups
- Fix weird font rendering in certain menus.
- Fix dialog changing sizes by huge amount when changing languages
- Some minor changes from String::format to U32String::Format
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
- ButtonWidgets (Button, Radio, Checkbox, dropdown)
- StaticTextWidgets
- PopUpWidgets
- Tabs
- Add a temporary overloaded drawDDText function to make other widgets draw normally
- Fix last chars being eaten
- Add support for input in right-align mode editables
- Fix issue with dirtyness of editables after clicking
- Improve spacing for lists and popup
- Make numbers reversed in lists
DropdownButtonWidget is a button split in two parts vertically. Clicking
the left part triggers a default action. Clicking the right part shows a
list of other actions the user can choose from.
Using this widget on the launcher lets 'Mass add' be a secondary action
of the 'Add' button, removing the necessity of pressing the shift key to
access the feature.
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.
This is consistent with the notification when the widget changes by
clicking. As far as I can tell, that notification was added shortly
before mouse wheel handling was added. It missing from the mouse
wheel handler was presumably just an oversight.
Otherwise, it will look like the value hasn't changed until the
widget is redrawn for other reasons, e.g. by mouse-over.
Incidentally, does anyone know why handleMouseDown() calls
sendCommand() when the selection changes, while handleMouseWheel()
does not?
