Tweaked the subject to cleanly separate these things again
now it's off the hell platform :)
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.
And the toolbar Action menus look different to how they used to, but
that's a change Kirigami forced on us. The left/middle/right thing
is gone, now it just fits as many things as there are room for and
puts the rest in a context menu - but I haven't done anything to
significantly change that menu structure otherwise. There's a few
things we probably should look at, like the location submenu, which
only has one option in it - but that's stuff we can talk about after
the Necessary Changes land and easy to fix later so I haven't taken
any liberties with stuff like that.
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 there's the question of whether we drop support for Diveshare
(#4644 [1]), but I haven't done anything to act on that yet either
until someone who Knows clarifies its status.
Yes we should. Clearly dead.
Cool, leave that one with me then. I had to already change that
internally for the new QML, but hadn't otherwise changed its
function, so I'll just kill the Diveshare handling code as part
of this changeset.
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 ;)?
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.
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.
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).
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.
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?
But I won't be sad at all to only run the desktop version on it
for Real Use, I only put the Android version on it for testing
if some bugs I was looking at were something I introduced or
Always There. So it was mostly a question of if anyone else
might be.
I find a LOT of C++ code just incomprehensible.
I think it's one of those deeply ancient self-defence things where no
matter how hungry you are, your brain still recoils in horror and tells
you Don't Eat The Poison Berries!!
It was really hard to fight down with QML, I totally did not want to
waste my life learning something so obviously and horribly misguided
and my eyes would just glaze over.
But given the choice between fighting that down, or not having nice
toys that I really wanted. It's become a bit of an eat your damn
veggies thing, and I've been learning how to cook it to be a little
less unpalatable.
That and a lot of C++ code that some people write really *is* just
horrible :)
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.
And Modern C++ (as opposed to the original "C with Classes" that I
first really liked) has fallen into that trap a bit too, but I know
it, so I think anything I might think python could be right for is
just easier to do in it.
The swipe at perl "there's only one way to do it" thing was cute,
until the fine print of (per version of python) started rearing
its head.
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!
Ron
_______________________________________________
subsurface mailing list -- [email protected]
To unsubscribe send an email to [email protected]
