When starting to scroll, the current line is added to the history
so that if we scroll up and then down we get it back. This was
initially implemented correctly, but borken later on in 51dceaf1659
when the history was changed to use Common::String.
This should address the #13106 issue and similar
It makes widgets, who don't implement handleMouseWheel(), call the handleMouseWheel() of their parent by default
Logic is borrowed from how widgets forward unhandle commands to their parent in handleCommand()
Add a class to group all renderer related (static) functions.
This allows to have getBestMatchingAvailableType inline in all engines.
The matching code is now shared between all engines but allows
customization for engines needing it (Grim, WME3D).
The new code takes runtime availability of features to select the
best renderer.
It avoid crashes when user choosed OpenGL but GLES2 is used.
Clicking on a checkbox (and, presumably, a radio button) would leave it
in the "pressed" state, which would inhibit tooltips for it. Now the
unpressed state is cleared along with _duringPress for both these
classes. There are other widgets that inherit from ButtonWidget, but
they either already did this, or didn't override handleMouseUp(), so
they should be fine.
A defaultCommandProcessor let's an engine take over the processing of
commands in the debugger. The Director Engine uses the functionality to
implement a repl for the Lingo language.
Example Usage:
registerDefaultCmd(WRAP_DEFAULTCOMMAND(Debugger, lingoCommandProcessor));
The input will now be handled by lingoCommandProcessor. Other commands
will not work untill control is given back to the debugger.
It's up to the engine to return control to the debugger when done.
To return control, call it with a nullptr:
registerDefaultCmd(nullptr);
Fix bug https://bugs.scummvm.org/ticket/13339
Solution is taken from our ListWidget (gui/widgets/list.cpp) which performs a similar check in its ListWidget::getEditRect()
This happened after calling scaleGfx if the original surface was
already at the correct size. In such a case scaleGfx returns the
original surface, so it should not be freed.
* GUI: rename buttons
Rename Edit Game to Game Options and Options to Global Options to make it less confusing.
Remove ellipsis on launcher buttons.
* GUI: put ellipsis back
* GUI: abbreviate options button texts for lowres
* GUI: use 320 width for lowres
* GUI: remove ellipsis from About button
The theme files were modified in c80adc3e, and the theme version was
incremented in the theme files, but not in the ThemeEngine, causing
a discrepency.
It's hard to make this appear only on EGA Loom, so the tooltip has to
document the fact that it's only useful there. The setting is made
relative to the default tempo, which I feel is a much more sensible way
of presenting it to the user than the raw ticks value.
Apple's desktop operating system was formerly called "Mac OS X" and "OS X", but since 2016 it has been called "macOS" (starting with version 10.12).
Changing across all comments and documentation to use this current terminology, except in cases where the historical versions are explicitly referenced. No code changes are made; we should consider changing those in future PRs.
The current recommended and de factor behavior from both Microsoft and Apple is to have "About" menus be without trailing ellipses. Therefore, I think we should follow suit.
Traditionally, About menus and buttons had a trailing ellipsis. [This article](https://uxdesign.cc/dot-dot-dot-7ce6170bfc7f) demonstrates this behavior for both Mac OS 1.0 (technically "System 1.0") and Windows 1.0.
However, current versions of macOS and Windows do not have a trailing ellipsis in About menus. Moreover, their design guidelines recommend not using them. From [Apple](https://developer.apple.com/design/human-interface-guidelines/macos/menus/menu-anatomy/):
> Use an ellipsis whenever choosing a menu item requires additional input from the user. The ellipsis character (…) means a dialog or separate window will open and prompt the user for additional information or to make a choice.
Since no additional input is required from the user for the About menu, it is inappropriate to use an ellipsis according to these guidlelines.
Microsoft [explicitly says](https://docs.microsoft.com/en-us/windows/win32/uxguide/ctrl-command-buttons) that About menus should not have an ellipsis (emphasis mine):
> This doesn't mean you should use an ellipsis whenever an action displays another window only when additional information is required to perform the action. Consequently,** any command button whose implicit verb is to "show another window" doesn't take an ellipsis, such as with the commands About**, Advanced, Help (or any other command linking to a Help topic), Options, Properties, or Settings.
Given all this, I think we should be in line with current best practices and remove it from the menu.
