System themes are temporary disabled
Theses Contexts defines what palette they use (the standard one of the dark one
in the player), what color set they should use (is it a button, a slider,
etc..), and the state of the widget (hovered, focused, pressed, disabled). The
context defines some color properties that may be usable in the current widgets
(different colors for foregrounds, backgrounds, and decorations)
* For each color, we build a key representing the color, the key is build from
the color set (button, window, view, tabbutton, etc..), the section
(background/foreground), the name (primary/secondary/...) and the state
(normal, hovered, focused, pressed, disabled).
* all colors are stored in a map associating the color key to its value
* When a color is required for a particular context, we look in the table for
the key. There is a fallback mechanism, if the key doesn't exists for a given
state, we try to rebuild the key for the `Normal` state. then if the key
doesn't exist for this component we rebuild the key for the `View` component
(first with the actual state then with the `Normal` State). if every thing
fails we return a crappy color (magenta) to visually indicate that something
needs to be fixed.
* On the QML Side, we instantiate a ColorContext object for each component we
want to theme, and we extract colors from it. there are 3 main sets of colors:
* `fg` for foreground colors, the sub colors are `primary` (the main color),
`secondary` (for component that requires a second color), `hightlight` (for
selection), `link` (for links), positive/neutral/
* `bg` expose the same set of color but for background
* decoration colors. theses are directly accessible in the `ColorContext`
object. `border`, `separator`, `accent`, `shadow` and `visualFocus`
ColorContext have a palette property that defines which palette should be use
(dark palette for the player or default palette), a `colorset` to define what
is the current color set (Button/View/Item/Slider/etc...) and some state
(enabled, focused, hovered, pressed)
When a color change due to either a state change or a palette change, the
color property change is signaled and the color will be changed through
property bindings
default values are provided by the dark/light theme, colors are then overriden
by the system themes this will be less tedious than using qml states to switch
values. This will also allows system theme to specify colors beyond QPalette
QT_STATICPLUGIN is meant for building a static Qt plugin [1], and not for
testing if the used Qt is a static or shared build: That should be done
with QT_STATIC. Since we are not building a static Qt plugin, use
QT_STATIC.
1. https://doc.qt.io/qt-5/plugins-howto.html#creating-static-plugins
this allows to template SVG assets with placeholder colors that will be replaced
with theme aware colors at runtime. the substitution is made while reading the
SVG using simple string substitution.
placeholder colors are pre-defined as
color 1 -> #FF00FF
color 2 -> #00FFFF
This patch contains the three QmlMenu(s) required for the Tracks panel:
QmlTrackMenu, QmlSubtitleMenu and QmlAudioMenu. The video tracks do not
require a dedicated menu for now.
this allows to store error messages before the UI is loaded and not to miss
dialogs messages if they are requested before the QML is ready.
fix: #26111
Note that in some cases they have been changed to forward declarations, and
in some they have been moved, for instance inclusion of `<QUrl>` was moved
from `qt.hpp` to where it was needed.
Types are used in connections, they must be registered with both Q_DECLARE_METATYPE
and qRegisterMetaType as stated in the documentation.
> To use the type T in QVariant, using Q_DECLARE_METATYPE() is sufficient.
> To use the type T in queued signal and slot connections,
> qRegisterMetaType<T>() must be called before the first connection
> is established.
Fatih Uzunoglu