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.
Also remove the unused linesWidth variable and fix the hlLeftPadding and
hlRightPadding widget attributes to actually work.
There are still issues remaining with the caret in the list widget due
to the ellipsis being used to shorten long text. Ellipsis is accounted
for when drawing the text but not when computing the caret position.
The previous combination of a fixed 10 milliseconds delay and time since
last update checks meant that in most cases 20 milliseconds elapsed
between two calls to updateScreen resulting in a 50 fps framerate. On
systems with wait for vsync enabled that meant that some frames were
missed.
The new frame limiter waits for a variable delay equal to the non
consumed time in the slot allocated to the frame.
Previously, a C-style cast was used to convert a
Common::Array<Plugin *>, populated with pointers to StaticPlugin
and DynamicPlugin instances, to a
Common::Array<PluginSubclass<T> *>, but PluginSubclass<T> is a
*sibling* class to StaticPlugin/DynamicPlugin, so this cast was
invalid and the results undefined. The methods for retrieving
subclasses of plugins can't be easily changed to just generate an
array of temporary wrapper objects that expose an identical API
which dereferences to the preferred PluginObject subclass because
pointers to these objects are retained by other parts of ScummVM,
so the wrappers would needed to be persisted or they would need to
just re-expose the underlying Plugin object again. This indicated
that a way to solve this problem is to have the callers receive
Plugin objects and get the PluginObject from the Plugin by
explicitly stating their desired type, in a similar manner to
std::get(std::variant), so that the pattern used by this patch to
solve the problem.
Closes gh-1051.
Updating the list reset the selection in the list widget, however if
a save had previously been selected and the Choose button was enabled,
it remained enabled despite no save being selected. Trying to load
the game resulted in a crash. This was particularly an issue with
cloud enabled as if you are unlucky you could have tried to load a
save just as the cloud sync finished, which updated the list and
unselected the save. This change fixes bug #9766: Assert in
SaveLoadChooser dialog.
In addition to adding a sanity check on the selected index for the
Choose command, this commit also preserves the selection when
updating the list as I think this would be the expected behaviour
in this dialog.
Removing this GUI control was suggested as far back as 2011 at
<http://lists.scummvm.org/pipermail/scummvm-devel/2011-November/010416.html>.
There were no objections, but it was never removed. When working
on audio latency bugs, I independently rediscovered that the GUI
option was broken: the per-game options would *never* work, and the
option would not take effect until ScummVM was restarted because
there is no API for interacting with the backend audio mixer. So
now, it is finally gone.
Primarily for the sake of future troubleshooting, configurability
of the audio sample frequency within SdlMixerManager is maintained
for the moment, but now users will need to edit their ScummVM
configuration file manually to change it.
c19c10d548 fixed the bad parsing of
module.mk which meant the Xcode generator broke. For the moment,
just move the hack for browser_osx.mm into the generator, until
there is a more elegant solution to this problem (if ever).
stdout may be buffered, in which case debugger messages are
delayed until a newline is written. The same kinds of calls to
OSystem::logMessage are flushed, so this just seems to be a simple
omission on this non-default code branch.
This is an attempt to fix a difficult to reproduce issue where the NSOpenPanel
remains open in the background and locks the application. Some tests suggest
that it might fix the issue, but only time will tell.
This fixes tons of warnings with clang from a recent xcode version on
macOS (and possibly other systems) complaining that an instantiation
of _singleton is required but no definition is available.
When widget::draw() is called it asks the ThemeEngine to redraw the background
first and then the widget gets redrawn in drawWidget(). The ThemeEngine uses
an extended rect to restore the background to include bevel and shadow effects.
However if this extended rect overlaps with other widgets, since those other
widgets are not redrawn, a part of those will be missing. See for example
bug #6394: GUI: List View save page drawns over font.
In case we get overlap we might need to change the way widgets are drawn so
that all widgets intersecting the area where the backgroud is restored are
redrawn. This commit simply seperate the bevel and shadow effects, and uses
the shadow offset only to extend the bottom and right sides of the rectangle
(while the bevel offset is still used to extend all four sides). This
results in a smaller extended rectangle (if the shadow offset is bigger than
the bevel offset, which is the case of the list view) and thus decrease the
risk of the issue happening. The particular cases described in bug #6394
are all fixed with this change.
PR#921 changes the behavior of the client that if the GUI fails to be
rendered the previously applied settings in the misc category are
restored. Error messages were altered according to the changes.
Bug: #9717 GUI: Indirectly changing 'GUI Language' can produce
inconsistent behaviour when changing some options.
The issue was with the focus or mouse widget as it may not be a
direct child of the dialog (it may for example be a child of the tab
widget in the options dialog) and removing a widget was not
resetting the mouse of focus widget if that widget was not a
direct child.
This is achieved by adding a list of GuiObject to delete to GuiManager
and doing the deletion in GuiManager::runLoop.
The main purpose of this is to avoid the deletion of ButtonWidget object
while their ButtonWidget::sendCommand function is being called. For
example the sendCommand of the Apply button of the OptionsDialog
may cause a rebuild (if the GUI language was changed) which tries to
delete the widgets inside the OptionsDialog, including the Apply button.
The theme label in the Misc tab will not change to the correct theme
when current language and theme is changed and 'apply' pressed.
loadNewTheme() does not do a rebuild of all widgets, including the
theme label, like it is explicitly done in the 'language section'.
The problem is that rebuild() uses the currently applied settings to
rebuild all widgets. Although a new theme was selected by the user the
label will be overwritten with the name of the still active theme.
By rearranging the logic a complete rebuild of the GUI is done and
updates the widgets correctly.
