This commit will
1. Register the QmlAudioContextMenu, a Right-Click popup menu for Music Playback in mainui.cpp
2. Implement QmlAudioContextMenu in qml_menu_wrapper class
3. Add close() function for player menus:
QmlGlobalMenu
QmlBookmarkMenu
QmlProgramMenu
QmlRendererMenu
we don't need to store the image provider inside the medialibray as it's only
useful to the QMLEngine. We only needed it fot crafting URL, but this can be
done with a stateless function.
QML types need to be cleared for two reasons:
- Protected modules do not allow new type registrations.
- It does not make sense to re-register same types.
This is currently the case if a compositor fails when
initializing the quick view.
Note that `qmlClearTypeRegistrations()` is effective on
protected modules as well.
It is a known bug from Qt's side that once Qt Quick view
(engine) is fully initialized, re-initialization is flaky
and causes crashes. See QTBUG-113274. Unfortunately this
does not fix that issue.
IDE such as QtCreator provides code completion qmlRegistered types, as the uri
is a variable the introspection function doesn't know in wich namepace the
classes belongs, adding this kind of annotation fixes the introspection
artwork may reference a network resource, so far we were using QNetwork to read
these resources, but it has some drawbacks
* The protocol for the artwork may not be handled by QNetwork
* The access to the artwork may require credentials that will likely be the same
as the one required to access the media
* QNetwork may not be present as this is not a requirement for building VLC
Image may require to be loaded using VLC access using special URI image://vlcaccess/?uri=......
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
Darshan Jain
Pierre Lamot
Fatih Uzunoglu
Prince Gupta
Mohit Marathe
Steve Lhomme
Yann Lochet
Benjamin Arnaud