> On Jan 16, 2026, at 08:57, Ron (Subsurface) via subsurface
> <[email protected]> wrote:
> On 2026-01-16 03:31, Dirk Hohndel via subsurface wrote:
>>> On Jan 15, 2026, at 08:16, Ron wrote:
>> The one person who loves the pink color scheme that I added as a joke
>> will be sad 🤣
>
> Oh I am so glad to hear that, I was actually a little worried that
> someone would be genuinely heartbroken about that! It is by far the
> most 'immediately obvious' difference.
Well that one person started this project. And I can confirm that he does,
indeed,
still run the app in HOT PINK. 🤦🏻♂️
>> I love updates that make things "better" meaning "different" meaning
>> "surprising to users". Oh well.
>
> Indeed. Though I think this one feels worse for being on the "how to
> fix the code" side of it. There was no guidance about what they had
> changed or how they expected maintainers to migrate, I had to dig
> way back through their git logs to get a sense of that. From the
> user-facing side, it's Different, but shouldn't be too confusing,
> or probably even unwelcome after the initial shock.
>
> So just saying that *I* wouldn't have changed this without broader
> consultation if that had of been an option.
And this will be the third time they did exactly that. That center button is
something that they love to mess with.
>>> There's a few new settings knobs, mostly for things that we were
>>> using somewhere but not letting you actually set in the mobile
>>> version, and I've just rehashed the Dive Summary page to let you
>>> pick arbitrary intervals to show those stats for, partly as a test
>>> bed for getting a better handle on issues with handling dates, but
>>> also because it's just a useful extension to that which was easy to
>>> add.
>> I'm not sure what you mean by that, looking forward to seeing this.
>
> Does anyone really still use VPM-B (he says putting on a helmet for
> fear of more passionate emotional fallout from someone ;)?
I see questions about it now and then. I think most people who use it
use it because it's there. But I might be wrong. Robert might have more
data. Maybe
> There were things like the planner using the conservatism level set
> for that, but not giving you any way to actually change the hardcoded
> default from the mobile UI.
Remember that the mobile UI is a fairly recent feature, single handedly
developed by one enthusiast. I wouldn't be surprised if there were more
little oddities lurking in that. It's hard to get these UIs right, as you know.
> For the Dive Summary, instead of being able to pick from a list of
> 1/3/6/12 months, you can now choose (for either column) an arbitrary
> start and end date for the period, or some integer number of months
> or years prior to the end date.
>
> It still defaults to "all dives" in one column and the previous 12
> months in the other, and isn't otherwise notably different.
Not sure who needs that (my reflexive desire for fewer options, more
simplicity raises its head), but it does sound reasonable.
>>> We can export and import XML files now (including saving them to the
>>> local file system), because Android mechanisms for that are
>>> convoluted, but not quite as nasty and restrictive as they were
>>> looking to be for a while in the past, and that was kind of a spin
>>> off benefit to getting the email support working.
>> The challenge with this is that the APIs for this changed at least
>> three times, and we have people using the Android app on positively
>> ancient versions of Android (at least one user I get occasional email
>> from on Android 7). But if you have something that works, that's a
>> very frequently requested feature - even if it doesn't work on all
>> Android versions, it might be worth while.
>
> My (not that) old phone will never get an update past Android 7, so
> it still runs the old final play store version. My newer phone went
> from Android 15 to 16 in the middle of working on all this, and
> because we need bleeding edge Qt for correct safe-area handling on
> those, it's going to cut off anyone older than Android 9 (API 28).
The price of progress? Android 9 feels like an acceptable tradeoff.
> So we'll either need an archive of older APKs, or someone will have
> to step up to continue to maintain an older branch for earlier devices.
>
> I don't like it, but again it's the True Cost Of Living in the Qt and
> Android space, and there's not much else we can do about it.
Indeed. And we already have that with other platforms (people running
Subsurface on macOS 10.9 -- just got an email from one of those a few
weeks ago because of a cloud problem. And yes, they are on an
ancient version...
>> I believe Android on x86 is dead as a doornail. I was at Intel when
>> that pipe dream was laid to rest a decade ago. Sure, I even have two
>> x86 Android devices in a drawer (no idea if they would turn on), but
>> that's... not something I worry about. We have only had arm64 binaries
>> for quite a while now.
>
> Cool, that makes me happy, though a tiny bit confused. I have a
> chromebook (and don't get me started on how horrible it's turned
> out to be), which I got as a "I don't care if it's lost or broken"
> device for moving the content of SD cards to bigger storage, and
> to run the planner on when traveling - and it can run both
> Real Linux, in a horribly restricted jail, and Android apps - so
> I can run both versions of Subsurface on it, and the current APKs
> do work on it (after you find the deliberately obfuscated way to
> click past the scary, OMG security warnings).
>
> Except I'm pretty sure it's Android x86? And I thought I saw the
> docker image for the github build was building all archs?
Hmm...
% git grep -i android | grep -i armv
packaging/android/install-qt.sh: any, android_armv7,
android_arm64_v8a
packaging/android/install-qt.sh: any, android_armv7,
android_arm64_v8a
packaging/android/install-qt.sh: any, android_armv7,
android_arm64_v8a
% git grep -i android | grep -i arm64
packaging/android/install-qt.sh: any, android_armv7,
android_arm64_v8a
packaging/android/install-qt.sh: any, android_armv7,
android_arm64_v8a
packaging/android/install-qt.sh: any, android_armv7,
android_arm64_v8a
packaging/android/qmake-build.sh: ANDROID_ABI="arm64-v8a"
packaging/android/qmake-build.sh: ANDROID_ABI="arm64-v8a"
Always possible (hey, likely) that I'm missing something... but our script
seems to only build arm64-v8a ?
>> Excellent. So not a QML fanboy, but a QML victim with experience.
>> Works for me.
>> And hey, I used to hate Python and with Python 3 I have gotten to the
>> point where I actually write more Python than C/C++ code.
>
> I've tried to like python. A few times now, I really have.
>
> But I love C and Perl and POSIX shell because stuff I wrote in them
> years ago Still Works Today, and I haven't had busywork forced on me
> to rewrite things that didn't need changing just because someone
> pulled the foundation out from under them.
Yeah, that is definitely NOT true for Python 3...
> I do actually use python fairly often, but not to write code, it
> is a nice no-nonsense command line calculator when I just need
> to do some quick math! Though typing that extra 3 to bring it
> up does still look like a poison red berry to me!
My other main open source project that I work on these days is almost
completely Python 3
Well, now that I checked, GitHub says:
Python 68.9%
HTML 19.5%
Shell 10.7%
Other 0.9%
Oh well. Still, predominantly Python...
/D
_______________________________________________
subsurface mailing list -- [email protected]
To unsubscribe send an email to [email protected]
