This has now been verified to work on a fresh clean Ubuntu 20.04 install, both
using the docker image route as well as the full local build system.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The way I test things locally I build in the directory above the subsurface
directory. Let's match this on GitHub as well.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
19.10 is no longer receiving updates and causing problems when running
the tests. 20.04 also uses Qt 5.12.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This seems more consistent with how we do things elsewhere.
Also make sure that the ssrf-version.h file is created in the correct
directory.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since the integrated build no longer seems to work, this creates a separate
Kirigami build using qmake (as I couldn't make Kirigami's cmake build work).
The install target tries to install into the Qt install which may not be
possible with a user account, so this instead uses the built library directly.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I stumbled across needing this when trying to build Kirigami via cmake (just
like on Android). I abandoned that attempt, but there seems to be no harm in
adding this.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This of course needs to be fixed in the build container itself, but
for now this might be enough to make progress.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
That's what happens if you develop a script like this sequentially.
We need to have the ABIs picked in order to build googlemaps, otherwise
this fails with the build container as that only includes the ARM
libraries and tools.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the OS has an older one installed, that is found first and the
build fails. This way we know that ours is used.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In order to apply the patches for Kirigami, git insists on having
a valid user name and email.
Also, don't build the mobile app when preparing the AppImage. That
build already takes way too long and we test this in a few other
actions.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It appears that the Kirigami shaders aren't bundled with the app. They
should be part of the plugin, but somehow they aren't. This way things
at least 'mostly work'.
We also need the icons. And to make this a bit more structured, move
those resource declarations into the Android part of the qmake file
until we know how all this works out on iOS.
The Android app is still fairly unusable with all kinds of weird font
problems and many other issues, but at least it once again starts.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So while the documentation explicitly says that you need to have the
getInstance()registerTypes() call, that clearly is not supported if you
build kirigami as a library. Even the required include file doesn't
exist in the install-root.
So let's try some other way to make this work. Heck if I know what the
correct way of doing this might be.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Doing it this way using the cmake build system at least gets us to the point
where everything links and appears to fit together. It still doesn't work at
all, but hey, progress.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And don't try to build kirigami in the same qmake run. The inclusion of the
.pri file doesn't appear to lead to a build that works.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Having them as commits like this should make it easier to migrate them
as we update the underlying Kirigami version.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
These should already be part of the kirigami plugin, but without explicitly
adding them here they appear to not get found at runtime.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With the updates to Kirigami I slightly modified the hack that we use to
implement that, as a result we call pop() directly on the globalDrawer.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of relying on this being available as a system resource, treat it
the same way as we treat Kirigami and the Breeze icons.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Our half-assed manual build of Kirigami was becoming completely unmaintainable.
So let's try to use the build method that the Kirigami team recommends. Which
unfortunately requires us to have access to the KDE extra cmake modules (ECM).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Recently (d16a9f118a) the tankinfo table was made dynamic, which
means that the default tankinfos are added programatically.
Thereby, the wrong function was used for AL* type of cylinders:
metric instead of imperial. Fix those.
Reported-by: Michael Andreen <harv@ruin.nu>
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
A user complained about the default cylinders list. Provide
a preferences option to turn this off.
When changing the preferences, the tank-info model will be
completely rebuilt. Currently, this is a bit crude as this
will be done for any preferences change.
Suggested-by: Adolph Weidanz <weidanz.adolph@gmail.com>
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There was a tank info with an empty name. According to a comment,
this is needed for the "no cylinder" case. However, we now support
empty cylinder tables, so this is not needed anymore. Therefore,
remove it.
Make sure that the user can still enter the empty name, just in
case. But don't save the size and pressure in that case.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There seems to be no point to saving data to the tank with
the empty name. Don't save tank-pressure and size to that
tank info.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This is obviously a pure code-hygiene thing. But with the new
dynamic tank info table, this becomes trivial, so let's do it.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The list of known tank types were kept in a fixed size table.
Instead, use a dynamic table with our horrendous table macros.
This is more flexible and sensible.
While doing this, clean up the TankInfoModel, which was leaking
memory.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The mainwindow was connecting preferences changes to the profile.
Do this directly in the profile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
These are the small dots that describe dragable points on
the profile when in the planner. It makes no sense to have
them in desktop's planner-widget code. They belong to the
profile.
Therefore, move the code there and compile on mobile.
Not everything can be compiled on mobile for now, but it
is a start.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This function, which removes the handlers from the profile, was called
in setAddState() but not in setPlanState(). In the latter case it was
called explicitly by the caller.
Move the call from the caller into the function. This allows us to
make clearHandlers() private in to the profile widget.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Around 2015 there was a push to move planner UI code from
mainwindow.cpp to diveplanner.cpp. That never was completed,
presumably because the planner is actually three widgets.
Collect these widgets in one PlannerWidgets class and move
the code there.
This is not a full dis-entanglement, as the plannerwidgets
have to access the profile via the mainwindow. But at least
it collects the planner UI code at a single place.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In the list view two functions were still manually collecting
the selected dives. Use getDiveSelection() there as well.
Careful: that means that the check for dives that are already
outside of a trip now has to be done in the RemoveDivesFromTrip
command.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The main window called a function to init the header actions
(i.e. the context menu) of the dive-list. There is no reason why
this shouldn't be done in the constructor of the dive list, since
it only accesses the QSettings, which are available at application
startup. This improves modularity of the code (by a tiny, tiny bit).
Moreover, the initialization function was at the same time the
header-reloading function. That function can now be folded
into the settings-changed function, since that is the only
remaining user.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Weirdly, the settingsChanged() signal of the dialog-pages was
connected() to the settingsChanged() signal of the dialog
every time the settings were accepted. Do it only once
in the constructor.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This function was called when opening the preferences dialog
to update all the pages with the current preferences.
For unknown reasons it also removed / readded all the pages.
Remove that code and use the now leaner function when refreshing
the pages.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
After each addition of a page in the constructor, the list was
resorted. This appears pointless. Instead, sort the list only
after all pages were added.
Since the add-page function is now a single line, remove it.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
