Re: [PATCH] Re: Time zones (again)

[Robert C. Helling]

Hi,

> Am 23.06.2016 um 04:17 schrieb Thiago Macieira :
> 
> The assignment on that second line erases any settings from the previous line.
> 
> If you want to parse *as* GMT, the only way to do it is using ISO format and 
> appending a "Z" to the target date. Something like
> 
>timestamp = QDateTime::fromString(date + ' ' + time + 'Z', Qt::ISODate);
> 
> Note: you need to ensure that the month, day and hour have leading zeroes.
> 
> Alternatively, parse date and time separately, then create the QDateTime from 
> the QDate and QTime objects.

Thanks for those comments. Will send an updated patch. 

Robert
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Re: Time zones (again)

[Thiago Macieira]

On quarta-feira, 22 de junho de 2016 22:47:33 PDT Robert Helling wrote:
> here is a patch which implements (I hope) what I promised. I did some quick
> checks in particular with the planner (there it indeed fixes a bug reported
> in the user forum which got me started in the first place thinking about
> time zones again) but maybe I did not cover everything. More testing might
> be advised. But looking at the code leaves me quite confident about it.


> + timestamp.setTimeSpec(Qt::UTC);
> + timestamp = QDateTime::fromString(date + " " + 
> time, "-M-d
> hh:m:s");

The assignment on that second line erases any settings from the previous line.

If you want to parse *as* GMT, the only way to do it is using ISO format and 
appending a "Z" to the target date. Something like

timestamp = QDateTime::fromString(date + ' ' + time + 'Z', Qt::ISODate);

Note: you need to ensure that the month, day and hour have leading zeroes.

Alternatively, parse date and time separately, then create the QDateTime from 
the QDate and QTime objects.

In many places:
>   QDateTime dt;
> + dt.setTimeSpec(Qt::UTC);
>[other code]
> - dt.setTime_t(gt.when - gettimezoneoffset(gt.when));
> + dt.setTime_t(gt.when);

Correct, but inefficient. Better would be:

QDateTime dt = QDateTime::fromTime_t(gt.when, Qt::UTC);

I've just realised that my recent changes in Qt 5.8 pessimises the default-
constructed QDateTime on 32-bit systems, compared to 5.7... gotta fix it.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Re: Time zones (again)

[Linus Torvalds]

On Wed, Jun 22, 2016 at 4:20 PM, Dirk Hohndel  wrote:
>
> OK, this has gone wrong so many times... Linus, Thiago, would you take a
> look at this and give an ACK if you agree that this is reasonable to take?

The patch looks good to me. The only case that isn't obvious is the
use of startTime, but that's apparently the one that actually fixed a
bug, so that makes sense too. The other cases all get rid of the even
uglier use of gettimezoneoffset().

So apart from the extra

  +#include 

that Anton pointed out to me, it all looks sane. I didn't *test* it,
but I assume Robert did, and it does look correct as a patch, and I
much prefer the Qt::UTC use over the nasty manual gettimezoneoffset()
games.

  Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Re: Time zones (again)

[Dirk Hohndel]

On Wed, Jun 22, 2016 at 10:47:33PM +0200, Robert Helling wrote:
> 
> > Am 21.06.2016 um 22:44 schrieb Linus Torvalds 
> > :
> > 
> > On Tue, Jun 21, 2016 at 1:43 PM, Robert Helling  wrote:
> >> 
> >> I didn’t mean init of subsurface. I meant init of QDateTime.
> > 
> > Yes, if that works, then that sounds like a good idea.
> > 
> > Linus
> 
> Hi,
> 
> here is a patch which implements (I hope) what I promised. I did some quick 
> checks in particular with the planner (there it indeed fixes a bug reported 
> in the user forum which got me started in the first place thinking about time 
> zones again) but maybe I did not cover everything. More testing might be 
> advised. But looking at the code leaves me quite confident about it.

OK, this has gone wrong so many times... Linus, Thiago, would you take a
look at this and give an ACK if you agree that this is reasonable to take?

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Set -std=c++11 flag for g++

[Thiago Macieira]

On quarta-feira, 22 de junho de 2016 14:59:49 PDT Dirk Hohndel wrote:
> > On Jun 22, 2016, at 2:49 PM, Thiago Macieira  wrote:
> > 
> > On quarta-feira, 22 de junho de 2016 22:47:23 PDT Anton Lundin wrote:
> >> @@ -73,6 +73,7 @@ elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL
> >> "AppleClang")
> >> 
> >>set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99 ")
> >> 
> >> elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
> >> 
> >>set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99")
> >> 
> >> +   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
> >> elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel")
> > 
> > You want to set it for AppleClang and Intel branches too. Do we support
> > building with MSVC at all?
> 
> No. MinGW, gcc and clang

Ok, so the "Intel" branch above must be on Mac and Linux, which means it takes 
the same syntax as GCC and Clang.

If it were on Windows, the syntax would be different, as it tries to be 
compatible with MS's compiler.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Set -std=c++11 flag for g++

[Dirk Hohndel]

> On Jun 22, 2016, at 2:49 PM, Thiago Macieira  wrote:
> 
> On quarta-feira, 22 de junho de 2016 22:47:23 PDT Anton Lundin wrote:
>> @@ -73,6 +73,7 @@ elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "AppleClang")
>>set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99 ")
>> elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
>>set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99")
>> +   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
>> elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel")
> 
> You want to set it for AppleClang and Intel branches too. Do we support 
> building with MSVC at all?

No. MinGW, gcc and clang

> Also note that GCC 6 defaults to C++14, so effectively this change 
> "downgrades" the default support. But that might be a good idea, to make 
> people using the latest GCC not add features that older compilers can't grok.

yes.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Set -std=c++11 flag for g++

[Thiago Macieira]

On quarta-feira, 22 de junho de 2016 22:47:23 PDT Anton Lundin wrote:
> @@ -73,6 +73,7 @@ elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "AppleClang")
> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99 ")
>  elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99")
> +   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
>  elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel")

You want to set it for AppleClang and Intel branches too. Do we support 
building with MSVC at all?

Also note that GCC 6 defaults to C++14, so effectively this change 
"downgrades" the default support. But that might be a good idea, to make 
people using the latest GCC not add features that older compilers can't grok.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Time zones (again)

[Thiago Macieira]

On terça-feira, 21 de junho de 2016 14:34:38 PDT Thiago Macieira wrote:
> Anyway, Qt API updated for 5.8:
> https://codereview.qt-project.org/163231

It has just passed CI testing and is confirmed now for 5.8.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Re: Time zones (again)

[Anton Lundin]

On 22 June, 2016 - Robert Helling wrote:

> 
> > Am 21.06.2016 um 22:44 schrieb Linus Torvalds 
> > :
> > 
> > On Tue, Jun 21, 2016 at 1:43 PM, Robert Helling  wrote:
> >> 
> >> I didn’t mean init of subsurface. I meant init of QDateTime.
> > 
> > Yes, if that works, then that sounds like a good idea.
> > 
> > Linus
> 
> Hi,
> 
> here is a patch which implements (I hope) what I promised. I did some quick 
> checks in particular with the planner (there it indeed fixes a bug reported 
> in the user forum which got me started in the first place thinking about time 
> zones again) but maybe I did not cover everything. More testing might be 
> advised. But looking at the code leaves me quite confident about it.
> 
> Best
> Robert

> From 24d2a7e53c387166a0301066931016dd114229e3 Mon Sep 17 00:00:00 2001
> From: "Robert C. Helling" 
> Date: Wed, 22 Jun 2016 22:46:22 +0200
> Subject: [PATCH] Unify handling of QDateTime time zone information

...

> diff --git a/qt-models/diveplannermodel.cpp b/qt-models/diveplannermodel.cpp
> index 16a2e40..613b260 100644
> --- a/qt-models/diveplannermodel.cpp
> +++ b/qt-models/diveplannermodel.cpp
> @@ -4,6 +4,7 @@
>  #include "qt-models/cylindermodel.h"
>  #include "core/planner.h"
>  #include "qt-models/models.h"
> +#include 

Nit-pickings but its a stray include.


//Anton


-- 
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH] Re: Time zones (again)

[Robert Helling]

> Am 21.06.2016 um 22:44 schrieb Linus Torvalds :
> 
> On Tue, Jun 21, 2016 at 1:43 PM, Robert Helling  wrote:
>> 
>> I didn’t mean init of subsurface. I meant init of QDateTime.
> 
> Yes, if that works, then that sounds like a good idea.
> 
> Linus

Hi,

here is a patch which implements (I hope) what I promised. I did some quick 
checks in particular with the planner (there it indeed fixes a bug reported in 
the user forum which got me started in the first place thinking about time 
zones again) but maybe I did not cover everything. More testing might be 
advised. But looking at the code leaves me quite confident about it.

Best
Robert
From 24d2a7e53c387166a0301066931016dd114229e3 Mon Sep 17 00:00:00 2001
From: "Robert C. Helling" 
Date: Wed, 22 Jun 2016 22:46:22 +0200
Subject: [PATCH] Unify handling of QDateTime time zone information
To: subsurface@subsurface-divelog.org

Subsurface uses "local time" which in particular means we never
display time zone information to the user. The user (and our file
format) only sees times like 5pm or 17:00. A better name than
local time (which could mean "local at the dive spot) would
be "watch time", the time displayed by the diver's watch when
she entered the water.

Internally, we store times as time_t, seconds since Jan 1 1970 0:00
UTC. Our convention for conversion between 5pm and time_t as always
been to treat 5pm as if it were UTC.

Then confusion arose since Qt's QDateTime (which is tied to UI elements
like QTimeEdit and similar) is time zone aware and by default assumes
the system time zone. So when we set a QDateTime to 5pm and then later
convert it to time_t we have to take care about the difference between
UTC and the system time zone.

This patch unifies our solution to this problem: With it, we set all
QDateTime's time zone to UTC. This means we don't have to correct for
a time zone anymore when converting to time_t (note, however, the
signedness issue: Qt's idea of time_t is broken since it assumes it
to be unsigned thus not allowing for dates before 1970. Better use the
millisecont variants).

We only need to be careful about time zones when using the current time.
With this convention, when assigning the current time to a QDateTime, we
need to shift for the time zone since its value in UTC should actually be
the watch time of the user who is most likely used to the system time zone.

Signed-off-by: Robert C. Helling 
---
 core/gpslocation.cpp  | 12 
 desktop-widgets/simplewidgets.cpp | 10 ++
 mobile-widgets/qmlmanager.cpp |  3 ++-
 qt-models/diveplannermodel.cpp|  2 ++
 4 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/core/gpslocation.cpp b/core/gpslocation.cpp
index 2a09758..260637b 100644
--- a/core/gpslocation.cpp
+++ b/core/gpslocation.cpp
@@ -476,8 +476,9 @@ void GpsLocation::deleteFixesFromServer()
while (!m_deletedTrackers.isEmpty()) {
gpsTracker gt = m_deletedTrackers.takeFirst();
QDateTime dt;
+   dt.setTimeSpec(Qt::UTC);
QUrlQuery data;
-   dt.setTime_t(gt.when - gettimezoneoffset(gt.when));
+   dt.setTime_t(gt.when);
data.addQueryItem("login", prefs.userid);
data.addQueryItem("dive_date", dt.toString("-MM-dd"));
data.addQueryItem("dive_time", dt.toString("hh:mm"));
@@ -522,8 +523,9 @@ void GpsLocation::uploadToServer()
Q_FOREACH(qint64 key,  m_trackers.keys()) {
struct gpsTracker gt = m_trackers.value(key);
QDateTime dt;
+   dt.setTimeSpec(Qt::UTC);
QUrlQuery data;
-   dt.setTime_t(gt.when - gettimezoneoffset(gt.when));
+   dt.setTime_t(gt.when);
data.addQueryItem("login", prefs.userid);
data.addQueryItem("dive_date", dt.toString("-MM-dd"));
data.addQueryItem("dive_time", dt.toString("hh:mm"));
@@ -607,10 +609,12 @@ void GpsLocation::downloadFromServer()
QString name = fix.value("name").toString();
QString latitude = 
fix.value("latitude").toString();
QString longitude = 
fix.value("longitude").toString();
-   QDateTime timestamp = 
QDateTime::fromString(date + " " + time, "-M-d hh:m:s");
+   QDateTime timestamp;
+   timestamp.setTimeSpec(Qt::UTC);
+   timestamp = QDateTime::fromString(date + " " + 
time, "-M-d hh:m:s");
 
struct gpsTracker gt;
-   gt.when = timestamp.toMSecsSinceEpoch() / 1000 
+ gettimezoneoffset(timestamp.toMSecsSinceEpoch() / 1000);
+   gt.when = timestamp.toMSecsSinceEpoch() / 1000;
 

[PATCH] Set -std=c++11 flag for g++

[Anton Lundin]

With Qt 5.7, they started to require c++11 support, and in 5.6.1 some
nullptr's showed up in QtAndroidExtras/qandroidfunctions.h, so now we
need to compile our c++ code with c++11 support in our compiler.

Signed-off-by: Anton Lundin 
---
 CMakeLists.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index cc7db13..8147468 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -73,6 +73,7 @@ elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "AppleClang")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99 ")
 elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99")
+   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
 elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel")
   # using Intel C++
 elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC")
-- 
2.7.4

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

quick update on Qt 5.7

[Dirk Hohndel]

I pushed the latest build of Subsurface-mobile for Android based on Qt 5.6 to 
the testing channel on Google Play. This seems to work fairly well.

And I made the changes necessary to build the Android version against Qt 5.7. 
Under downloads/daily you'll find a -1445 apk that is built against Qt 5.7
Before I push this to the play store I'd really love to get some more people to 
test this to make sure there aren't any oddities that I missed... but my 
initial testing didn't show any changes. Sadly, paste still doesn't work (I had 
been told that this was something that should now work on iOS and Android, but 
at least on Android that doesn't appear to be the case (and iOS I can't build))

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] WIP: use kirigami plugin instead of embedding in qrc

[Marco Martin]

On Wednesday 22 June 2016, Dirk Hohndel wrote:
> Push whatever you want to change into master and I'll see if I can continue
> to build an Android package. If that fails as well I'll just stay on the
> last Kirigami that worked.

I'll test a bit more this patch on android (and see if i can make it prettier) 
and then will merge next week then

> I have no time to spend on this. I'll start a new job next week and will
> have a LOT less time to spend on Subsurface overall.

unfortunate on subsurface part, but congrats and good luck :)

-- 
Marco Martin
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] WIP: use kirigami plugin instead of embedding in qrc

[Dirk Hohndel]

> On Jun 22, 2016, at 9:34 AM, Marco Martin  wrote:
> 
> This is the latest version:
> We now added a build time switch in kirigami
> to produce a static library (in that case doesn't even need extra-cmake-
> modules so no extra deps)
> 
> the build scripts are updated to link to the generated static library, even 
> tough is pretty ugly cmake, probably it should stop copying over kirigami to 
> a 
> subsurface directory.
> 
> for normal systems and android it should just work, didn't touch the iOS 
> build 
> script as i can't test it, but should be easy to make it "just work" on IOS 
> as 
> well, as it's just statically linking now as opposed to loading a plugin at 
> runtime that as far i understood tends to be a problem there.
> 
> I really want to merge that branch of kirigamy very soon, (i can put a limit 
> on merge around next monday or so) that would make such change in subsurface 
> necessary in order to keep working.

Just merge it. I hate the idea that Subsurface is holding you back.

Subsurface-mobile isn't even creating a working build for iOS right now.
I tried to switch to Qt 5.7.0. The Qt 5.7.0 installer packages for Mac are 
broken and
you aren't able to build iOS apps. Tried to switch back to Qt 5.6.0 and now my 
Qt 5.6.0
builds fail on iOS (engine.load("qrc:///qml/main.qml") creates no warnings or 
errors, but
engine.rootObjects() is empty.

So at this point I'm giving up on iOS. I've never actually released an iOS 
package, the
current packages on TestFlight are good for a few more weeks. Either by then 
someone
gets this to work, or I'll call it a failed attempt and move on.

Push whatever you want to change into master and I'll see if I can continue to 
build
an Android package. If that fails as well I'll just stay on the last Kirigami 
that worked.

I have no time to spend on this. I'll start a new job next week and will have a 
LOT less
time to spend on Subsurface overall.

No one else seems to be willing to spend 60+ hours a week on maintaining 
Subsurface-mobile.

Oh well

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] WIP: use kirigami plugin instead of embedding in qrc

[Marco Martin]

This is the latest version:
We now added a build time switch in kirigami
to produce a static library (in that case doesn't even need extra-cmake-
modules so no extra deps)

the build scripts are updated to link to the generated static library, even 
tough is pretty ugly cmake, probably it should stop copying over kirigami to a 
subsurface directory.

for normal systems and android it should just work, didn't touch the iOS build 
script as i can't test it, but should be easy to make it "just work" on IOS as 
well, as it's just statically linking now as opposed to loading a plugin at 
runtime that as far i understood tends to be a problem there.

I really want to merge that branch of kirigamy very soon, (i can put a limit 
on merge around next monday or so) that would make such change in subsurface 
necessary in order to keep working.

-- 
Marco Martin
From deac135488a4cb220a2e55e9c9a50d1d2ecab32e Mon Sep 17 00:00:00 2001
From: Marco Martin 
Date: Wed, 22 Jun 2016 18:17:25 +0200
Subject: [PATCH] use kirigami built in static mode

now kirigami needs to be built from 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 
---
 CMakeLists.txt  |  4 
 mobile-widgets/qml/mobile-resources.qrc | 32 
 packaging/android/build.sh  |  7 +++
 scripts/build.sh| 10 ++
 scripts/mobilecomponents.sh |  7 ++-
 5 files changed, 23 insertions(+), 37 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index cc7db13..36665f2 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -235,12 +235,16 @@ if(${SUBSURFACE_TARGET_EXECUTABLE} MATCHES "MobileExecutable")
 	else()
 		add_executable(${SUBSURFACE_TARGET} MACOSX_BUNDLE WIN32 ${SUBSURFACE_PKG} ${MOBILE_SRC} ${SUBSURFACE_RESOURCES} ${MOBILE_RESOURCES})
 	endif()
+ADD_LIBRARY(kirigami_static_library STATIC IMPORTED)
+SET_TARGET_PROPERTIES(kirigami_static_library PROPERTIES
+IMPORTED_LOCATION ${CMAKE_SOURCE_DIR}/mobile-widgets/qml/kirigami/build/src/libkirigamiplugin.a)
 	target_link_libraries(
 		${SUBSURFACE_TARGET}
 		subsurface_profile
 		subsurface_models
 		subsurface_corelib
 		${SUBSURFACE_LINK_LIBRARIES}
+		kirigami_static_library
 	)
 elseif(${SUBSURFACE_TARGET_EXECUTABLE} MATCHES "DesktopExecutable")
 	set(SUBSURFACE_APP
diff --git a/mobile-widgets/qml/mobile-resources.qrc b/mobile-widgets/qml/mobile-resources.qrc
index 6983533..2b4146c 100644
--- a/mobile-widgets/qml/mobile-resources.qrc
+++ b/mobile-widgets/qml/mobile-resources.qrc
@@ -24,38 +24,6 @@
 		icons/nocloud.svg
 	
 	
-		kirigami/qmldir
-		kirigami/Action.qml
-		kirigami/ApplicationWindow.qml
-		kirigami/BasicListItem.qml
-		kirigami/GlobalDrawer.qml
-		kirigami/ContextDrawer.qml
-		kirigami/Page.qml
-		kirigami/ScrollablePage.qml
-		kirigami/Icon.qml
-		kirigami/Heading.qml
-		kirigami/OverlaySheet.qml
-		kirigami/ApplicationHeader.qml
-		kirigami/AbstractApplicationHeader.qml
-		kirigami/AbstractApplicationWindow.qml
-		kirigami/private/PageRow.qml
-		kirigami/Label.qml
-		kirigami/AbstractListItem.qml
-		kirigami/SwipeListItem.qml
-		kirigami/OverlayDrawer.qml
-		kirigami/Theme.qml
-		kirigami/Units.qml
-		kirigami/private/AbstractDrawer.qml
-		kirigami/private/ActionButton.qml
-		kirigami/private/BackButton.qml
-		kirigami/private/ContextIcon.qml
-		kirigami/private/CornerShadow.qml
-		kirigami/private/DefaultListItemBackground.qml
-		kirigami/private/EdgeShadow.qml
-		kirigami/private/MenuIcon.qml
-		kirigami/private/PageActionPropertyGroup.qml
-		kirigami/private/PassiveNotification.qml
-		kirigami/private/RefreshableScrollView.qml
 		kirigami/icons/go-next.svg
 		kirigami/icons/go-previous.svg
 		kirigami/icons/handle-left.svg
diff --git a/packaging/android/build.sh b/packaging/android/build.sh
index 2213780..2eeb4b9 100644
--- a/packaging/android/build.sh
+++ b/packaging/android/build.sh
@@ -310,6 +310,13 @@ if [ "$SUBSURFACE_MOBILE" = "ON" ] ; then
 	pushd $SUBSURFACE_SOURCE
 	bash ./scripts/mobilecomponents.sh
 	popd
+
+	cd $SUBSURFACE_SOURCE/mobile-widgets/qml/kirigami/
+	mkdir -p build
+	cd build
+	cmake .. -DSTATIC_LIBRARY=ON
+	make -j4
+	make install
 fi
 
 if [ ! -z "$SUBSURFACE_MOBILE" ] ; then
diff --git a/scripts/build.sh b/scripts/build.sh
index 014d2d3..635f1b1 100755
--- a/scripts/build.sh
+++ b/scripts/build.sh
@@ -211,6 +211,9 @@ if [ "$BUILDGRANTLEE" = "1" ] ; then
 	make install
 fi
 
+
+
+
 # finally, build Subsurface
 
 if [ $PLATFORM = Darwin ] ; then
@@ -229,6 +232,13 @@ for (( i=0 ; i < ${#BUILDS[@]} ; i++ )) ; do
 	if [ "$SUBSURFACE_EXECUTABLE" = "MobileExecutable" ] ; then
 		cd $SRC/subsurface
 		bash ./scripts/mobilecomponents.sh
+
+		cd 

Re: Cross-compiling Subsurface-mobile from Linux to Android

[Dirk Hohndel]

> On Jun 22, 2016, at 4:30 AM, Willem Ferguson 
>  wrote:
> 
> 
> 
> On 20/06/2016 21:52, Axel Richter wrote:
>> Am 20.06.2016 um 21:14 schrieb Willem Ferguson:
>>> 
>>> I am downloading build components to cross-compile to Android (i.e. 
>>> generating an .apk file). I installed Android-ndk, Android-sdk (NOT 
>>> Android-Studio) and the JDK (version 1.8). None of these components 
>>> required any compilation or building to be functional. Below a few remarks 
>>> on the Android components. 
>>> 
>>> In order to start developing applications, you must install the 
>>> Platform-tools 
>>> and at least one version of the Android platform, using the SDK Manager. 
>> 
>> Dear Willem,
>> 
>> yes, you will need such tools, especially for 
>> 
>> 1) yes, you will need all the libraries twice - one for the (host) linux and 
>> one for the (arm7 in your case?) processor. 
>> 
>> 2) For this you will need the image, too. Downloable via the SDK manager. If 
>> you get the android SDK, you will have an image to run into ADB. 
>> 
>> Private suggestion: download eclipse - with the android part, I'm sure there 
>> is one. So you have all in one package. 
>> 
>> Axel.
> Simple questions from an ignorant person.
> 
> I am not sure how to install Qt for use on Android. For Subsurface-mobile to 
> run on Android, where should Qt be installed?
> 
> Destination platform:
> My intuition suggests to me that Qt-Android would need to be installed on 
> native Android, but does this come across as part of the Subsurface 
> application? I have never installed Qt on my Android device, yet I run 
> Subsurface-mobile. Looks like the version for Android is Qt V5.7
> 
> Source platform:
> What Qt version is required on the source (development) machine? I cannot see 
> that Qt for Android would be required on the Linux source machine, unless 
> this is somehow included as part of Subsurface-mobile? My Qt environment on 
> Linux is 5.5.1

Willem, you install everything on your Linux box, not on Android.
Look at https://help.ubuntu.com/community/AndroidSDK 
 to get an idea how this works

You'll need the SDK https://developer.android.com/studio/index.html#downloads 
 (don't get the IDE, 
just the SDK at the bottom)
You'll need the NDK https://developer.android.com/ndk/downloads/index.html 


And then here you can get Qt with the bits for Android 
http://www.qt.io/download-open-source/#section-2 


/D


___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cross-compiling Subsurface-mobile from Linux to Android

[Joakim Bygdell]

On 22 June 2016 at 13:30, Willem Ferguson 
wrote:

>
>
> Simple questions from an ignorant person.
>
> I am not sure how to install Qt for use on Android. For Subsurface-mobile
> to run on Android, where should Qt be installed?
>

Depending on if you use a distribution package or install QT from qt.io
there might be some differences.

Given that you do not use a distribution package there is a "Maintenance
Tool" that allows you to selectively install different QT modules.
The one you want is the "Android ARM v7".


> Destination platform:
> My intuition suggests to me that Qt-Android would need to be installed on
> native Android, but does this come across as part of the Subsurface
> application? I have never installed Qt on my Android device, yet I run
> Subsurface-mobile. Looks like the version for Android is Qt V5.7
>
> Source platform:
> What Qt version is required on the source (development) machine? I cannot
> see that Qt for Android would be required on the Linux source machine,
> unless this is somehow included as part of Subsurface-mobile? My Qt
> environment on Linux is 5.5.1
>
> Kind regards,
> willem
>
>
>
>
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>
// Jocke
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

RE: Cross-compiling Subsurface-mobile from Linux to Android

[Willem Ferguson]

On 20/06/2016 21:52, Axel Richter wrote:

Am 20.06.2016 um 21:14 schrieb Willem Ferguson:


I am downloading build components to cross-compile to Android (i.e. 
generating an .apk file). I installed Android-ndk, Android-sdk (NOT 
Android-Studio) and the JDK (version 1.8). None of these components 
required any compilation or building to be functional. Below a few 
remarks on the Android components.


In order to start developing applications, you must install the 
Platform-tools

and at least one version of the Android platform, using the SDK Manager.


Dear Willem,

yes, you will need such tools, especially for

1) yes, you will need all the libraries twice - one for the (host) 
linux and one for the (arm7 in your case?) processor.


2) For this you will need the image, too. Downloable via the SDK 
manager. If you get the android SDK, you will have an image to run 
into ADB.


Private suggestion: download eclipse - with the android part, I'm sure 
there is one. So you have all in one package.


Axel.

Simple questions from an ignorant person.

I am not sure how to install Qt for use on Android. For 
Subsurface-mobile to run on Android, where should Qt be installed?


Destination platform:
My intuition suggests to me that Qt-Android would need to be installed 
on native Android, but does this come across as part of the Subsurface 
application? I have never installed Qt on my Android device, yet I run 
Subsurface-mobile. Looks like the version for Android is Qt V5.7


Source platform:
What Qt version is required on the source (development) machine? I 
cannot see that Qt for Android would be required on the Linux source 
machine, unless this is somehow included as part of Subsurface-mobile? 
My Qt environment on Linux is 5.5.1


Kind regards,
willem




___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface