Hi there, After taking a pause for a while, I tried to address a couple of the bug reports for Subsurface-mobile on Android and iOS.
Right now we are building with Kirigami 1.1 and Qt 5.7.1. If we have to upgrade to Kirigami 2.0 and/or Qt 5.8 in order to make it easier for people to help us, please let me know... I tried with Qt 5.8.0 on the desktop and the two problems are still there. But I haven't tried Kirigami 2.0. So what's the issue? Quick background: Subsurface-mobile shows a dive list as it's first page - that's a vertical ListView that shows a couple of lines of data for each dive through a fairly simple delegate. The data comes from a model that is implemented as a QSortFilterProxyModel in C++. When you tap on one of the delegates, a new page is added which shows more information about the dive (most of that's in QML, but one pixmap with a visualization of the dive is rendered in C++). In order to be able to switch between dives by flicking that detailed view to the left or right, that "detail page" is implemented as another ListView using the same model, only with horizontal orientation. There's an "onCurrentIndexChanged" handler that keeps the outer and inner ListView in sync. Or at least that's supposed to do so. Lots and lots of debug prints seem to indicate that that part is working fine. Anyway, same model should imply that the same index means the same dive, so this should all work, right? We now run into two problems: a) under some circumstances (and we can reproduce this, but it requires the full app, we don't have an "easy to build test case to show the problem", sadly) when you tap on the dive with index N in the first ListView (the vertical dive list), the dive that is shown in the details view is actually dive N+1. I have spent several days trying to figure out why - no clue. The worst part is that in many scenarios it actually works correctly. b) under some circumstances (one is the case above, tap on N, it shows details for dive N+1, now in the vertical list tap on dive N again -- but there are other ways to get to this situation), things go crazy and the app will render ALL of the dives in the horizontal ListView (as shown by log message in the onCompleted signal handler for the delegate component) in the background. Depending on how many dives you have in the list, this will either hang the app for a considerable amount of time (tens of seconds) and then result in the correct page being shown, or it will crash the app, running out of memory. I understand that asking for help saying "hey, there is this massively painful to build app (at least we now have this fully scripted, so getting an Android apk or the Subsurface-mobile version for a Linux desktop is no longer quite as difficult - at this point it mostly takes a lot of time), can you help fix our bug" isn't really a great request. If anyone wants to take a look (both Marco and Sebas have contributed tremendously to Subsurface-mobile in the past, without their help we would never have gotten as far as we are), of course we'd appreciate it. But what I really was hoping for was someone saying "Oh, right, I've seen something like this, have you tried `.....'" If someone wants to try reproduce this, I'm happy to send information on how to get started building Subsurface-mobile. I can also point you to existing binaries in the app stores (Android, iOS) and sample data in order to reproduce the problem in case you want to see this in action. And as I said above, if you'd really rather have me update to Kirigami 2.0, I can make that higher priority and come back once that's done... I tried right around the time Kirigami 2 was released and had a rather frustrating time and kinda walked away from our mobile app in anger for a while... :-) Either way, thanks for reading /D
