In order to make sure we don't render the initial profiles with the
wrong scale on devices, we need to seed the device pixel ratio with the
device default and then update it once the window has been created.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of building a library that we link against, let's just use the .pri
file and include Kirigami in the primary build.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Now kirigami needs to be built with a C++ plugin.
In cases of mobile operating systems such as iOS (and in a lesser measuse,
Android) having a proper plugin loaded at runtime may be difficult, so
statically link it together with all of its qml files compiled as a
qresource inside the static library.
Signed-off-by: Marco Martin <notmart@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Having subsurface-core as a directory name really messes with
autocomplete and is obviously redundant. Simmilarly, qt-mobile caused an
autocomplete conflict and also was inconsistent with the desktop-widget
name for the directory containing the "other" UI.
And while cleaning up the resulting change in the path name for include
files, I decided to clean up those even more to make them consistent
overall.
This could have been handled in more commits, but since this requires a
make clean before the build, it seemed more sensible to do it all in one.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When running the QML UI on a Mac the deployment of the QML Components
seems to fail and the search path for the components is rather odd -
simply the same directory the executable was started from:
<bundle>/Contents/MacOS/
To work around this we need to manually copy the components at install
time to Contents/Frameworks/qml (not covered in this commit) and make sure
that we add the correct import path.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds qrc://imports to the paths that the Qml engine considers for
findings import plugins. This change makes loading the mobilecomponents
plugin work (it won't be found otherwise).
Signed-off-by: Sebastian Kügler <sebas@kde.org>
While this is primarily something targeted at a mobile device, with many
of the 2 in 1 devices it is possible that the user might be running the
desktop version of Subsurface on a mobile device.
As a first step to make it possible to collect GPS fixes on such a device
we need to make the infrastructure to do so available in the desktop
application as well.
This still needs to be hooked up in the desktop UI.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Oops. I fixed the previous commit, tested the fix, and then forgot to
update the commit and instead pushed it out. That was dumb.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
