No longer needed now that we use the full video view and we hide the window's real toolbar anyway
Signed-off-by: Claudio Cambra <developer@claudiocambra.com>
The module only works in non windowed mode (dummy window). And it doesn't report any size change.
So if the video placement changes that means:
- the source/user cropping has changed
- the source/user aspect ration has changed (unused here)
- the user zoom has changed (unused here)
- the filling mode has changed (unused here)
Ideally we would just update the dither locally, but we need the pitch of the
picture. Hopefully it's the same when the picture information don't change...
If the values used to create the dither, no need to force a re-creation.
Although Qt interface fails gracefully if
MainInterface.qml does not load properly,
The said file does not import all necessary
QML modules that are used throughout the
interface. Once QML engine encounters
an unknown module, the whole interface
becomes no longer usable as it asserts
all required modules to be present.
Some native tools we build may be usable by other targets.
When looking if a tool comes from the system we don't use our binary
folder so we rebuild it when its dependencies change or it needs a full rebuild.
A test should be disabled when one of their dependencies is disabled.
Currently every test using the full list of modules is disabled because
of that.
Regression from 146a4f4cd3.
It only generates C++ files which are not platform specific.
We already assume that a "protoc" binary with the proper version is a valid protoc version.
The scripts call just translate old options into their CMake counterpart.
The BUILD and BUILDPREFIX qt toolchain point to different build configurations.
The qt.toolchain.cmake corresponds to the toolchain file used by qt-cmake.
But we can't use it as it's supposed to be a tool for the cross-compiled
target. This toolchain file is the official one to use when cross-compiling Qt6
for Raspberry Pi in Qt Creator: https://wiki.qt.io/Cross-Compile_Qt_6_for_Raspberry_Pi
Protobuf and protoc version naming changed starting after version
21.7.11.x, at version 22.x.y[^2]. Other versioning changes during the
21.* cycle were made right before[^1].
The new versioning is described on the specific page from protocol
buffers website[^3].
For instance, protoc from archlinux currently outputs version 25.3,
leading to the following message if checking a 3-number version number
like the version in the contribs:
Program protoc found: NO found 25.3 but need: '25.3.0' (/usr/bin/protoc)
After this patch we have the following with version 25.3:
Program protoc found: YES 25.3 25.3 (/usr/bin/protoc)
and with version 21.1 from contrib:
Program protoc found: YES 3.21.1 3.21.1
[^1]: https://protobuf.dev/news/2022-05-06/
[^2]: https://protobuf.dev/news/2022-07-06/
[^3]: https://protobuf.dev/support/version-support/
Provide the necessary binary overrides throught the machine files
exposing the contribs, and ensure that the meson-machinefile built
depends on which binaries are built.
The new build tool generation uses a new PKGS.tools variable which
should match with the names used to find the different programs.
Not all programs can be found this way. For instance, it seems that the
Qt module from meson will completely ignore this parameter and load for
the Qt installation anyway.
Ensure that the meson-machinefile built depends on whether the script
has changed and on the latest state of the contribs. This will also be
used to depends on which binaries are built for the contribs.
Claudio Cambra