This allows to get application message written through console.xxx in qml or
qDebug logged as vlc messages. Qt internal messages are still sent through the
default Qt log handler
this avoids creating a new media tree listenner each time the NetworkDeviceModel
is created, especially since the the MediaSourceModel can be retained by NetworkItem
The models are closer to their counterparts from VLC:
- DeviceSourceProvider will expose each vlc_media_sources
- MediaSourceModel will expose each media belonging to a given media source
- NetworkTreeItem only reference it's origin media source rather than all the
sources from the agregated item from NetworkDeviceModel
When NetworkDevice model is destroyed, the source is unloaded which cause the
items to be removed, hence invalidating items from the tree. This caused
browsing devices sub-nodes to present empty views as their content were removed
when the device model was destroyed
libvlc_pipewire.la will be used to build libpipewirelist_plugin.la and libpipewiresrc_plugin.la.
This follows the same approach as using libvlc_pulse.la to build libpulselist_plugin.la.
It was added in mingw-w64 in [1] which is in v6, our minimum version.
We don't need to have it defined in UWP builds as we don't use winvlc.c.
[1] 36d7b92bbc
Initialise priority with VLC_META_PRIORITY_BASIC. Set the priority to VLC_META_PRIORITY_PLAYLIST
when metadata is detected after the `#EXTINF` or `#EXTALBUMARTURL` directives.
This is used to represent the priority of metadata for individual tracks in the m3u file.
This value will indicate whether the m3u file contains valid metadata for that track.
(VLC_META_PRIORITY_PLAYLIST if it does, VLC_META_PRIORITY_BASIC if it doesn't)
Turns out when switching views and deallocating the home view stack view
controller we were not emptying out the subviews for the actual stack
view, which had a reference held on it by the library window.
This means the created containers would stay alive and included in the
home view stack view's subviews... Then when switching back to the home
view we'd initialise a new home view stack view controller, which would
initialise new containers, and then add them to the home view stack
view, creating duplicates
Signed-off-by: Claudio Cambra <developer@claudiocambra.com>
When `m_setupStateCond.wait()` is called, the scene graph has already started
to initialize itself. So, 2.5 seconds waiting time was considered to be fair.
2.5 seconds were enough for Nvidia and VirtualBox drivers. However, it turns
out that AMD needs more time.
This is mainly relevant when the application starts with a video.
When scene graph encounters an error, we are already past the latest stage where
recovery is possible. The interface remains nonfunctional in this case, thus the
application must be terminated. This is already done by Qt itself when the signal
is not connected, but in this case we connect to the signal to let the waiting
video thread continue and to print the error.
Note that "If a signal is connected to several slots, the slots are activated in
the same order in which the connections were made". So, in this case exit is going
to be called after the error is printed, which is the intended behavior.
The hollow shader discards the pixels that are in the interior area. It
is known that branching in fragment shader should be avoided if possible.
By checking if the window is opaque, we can disable hollowing and use it
only if the window is translucent or transparent (due to window backdrop
blur effect).
The glow effect should not act as a filter for the window backdrop blur,
it is only used for providing a glow effect around the edges. This was
the reason of coming up with the possibility of hollowing.
Currently, areas of the interface that want to show the window backdrop
effect use a hack to "punch a hole" as they are placed deep down in
the scene graph hierarchy and in certain cases parent item(s) provide
background color.
This hack is done by simply disabling blending but still painting with
translucent colors (see `ViewBlockingRectangle`). In this case, it does
not really matter if the glow effect here is hollow or not, because the
areas that want to pass the backdrop effect disabling blending means that
the glow effect would not be visible behind those areas anyway.
However, "punching hole" hack has been used as a convenience when it is
necessary. In the future, the areas that want to pass the backdrop effect
should placed in the scene graph hierarchy so that there is no item in
beneath that is opaque. This is possibly impossible for the PIP player,
but there are currently places in the interface that this can be done,
such as the top bar. So, for these cases, we need hollowing so that the
glow effect does not appear (and act as a filter) in the interface main
area.
We already build Win64 with gcc and Win32 with LLVM.
This is redundant to test the code is building in the target and with the compiler.
There's also the UWP target that uses LLVM with the Win64 code.
We only need the nightly build which will only rebuild contribs when necessary.
