| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Prior to this change, a GUI layout was only affected by the screen size.
Now, a layout can additionally be influenced by the GUI dialog and widgets
that uses it. This capability is leveraged to implement the following
features:
* Layout elements that are not bound to a GUI widget do not take space.
This means that dialogs where the widgets shown depend on for example
a feature being enabled at configure time no longer have blank spaces.
* Widgets can define a minimal required size for their contents not to be
cut. For now this is only used for buttons so their width is always
sufficient for their caption not to be cut. This mechanism could be
applied to other widget types in the future.
|
|
The engineId, gameId and description come from static data in the game
engines. When the game engines are compiled as dynamic plugins, the QGD
structure may outlive the engine plugin. Making a copy ensures the data
remains available.
Fixes #11292.
|
|
|
|
Qualified game names have the following form: engineId:gameId.
Unqualified game names are still supported as long as they are not
ambiguous. However they are considered deprecated and are no longer
displayed by the --list-games command.
|
|
|
|
Fixes #10645.
|
|
This fixes bug #10634 - GUI: Options cutoff for Edit Game when
Graphics mode is x2 or less
|
|
ENGINES: Return unknown game variants with the list of detected games
|
|
|
|
|
|
|
|
|
|
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.
|
|
I think these are the last one that were already flagged as being
deliberate.
|
|
|
|
|
|
|
|
Minor mistakes which lead to build failure in some cases.
|
|
If that's the game, that is.
Method is copy-pasted from Launcher, but fixed not to ask the directory
and thus doesn't contain the loop.
|
