Hi Ron

> On Jan 27, 2026, at 15:38, Ron (Subsurface) via subsurface 
> <[email protected]> wrote:
> 
> And I think I am indeed currently in the process of Inadvertently breaking 
> it. :)
> Not seriously, just some minor but necessary refactoring of the start up
> sequence to ensure things like locale and font are always properly
> initialised before other things start to use them and commit to values
> that we may be about to change.
> 
> So if there's a new main() using much the same sequence as the existing
> ones, which is looks like there is, I'll need to tweak it once this is
> merged and I rebase my new work on yours.

I expect things to break. That's just life. And my current branch is more
invasive than I like it to be - a lot of it is just switching from

#ifndef SUBSURACE_MOBILE

to 

#if defined(SUBSURACE_DESKTOP)

but there are a bunch of places where I'm adding new ifdefs

> And just to be clear - I assume this means that export-html.cpp is going
> to go away completely once this is ready for production?  I had been
> updating its main(), but if it's going to die very soon, I'll just
> ignore it now.

Interesting question. I think the existing cloud storage is the MAIN user of
export_html -- but it wasn't actually written for that purpose. It really was
intended as an HTML export if that's what someone wanted.
Now WHY someone would want this, and what they'd do with it is an
entirely different question.

In other words -- yeah, unless someone yells loudly and soon, I'm planning
to remove that hack.


>>> As for organisation, I am not sure if we'd want to move the flask app
>>> and the web UI styling to a separate repository that consumes the
>>> subsurface repository as a submodule or by checking it out, in a
>>> similar way to how this is already done for our website in
>>> https://github.com/subsurface/new-website/ (or maybe even combine the
>>> two?).
>> Anything that isn't in the main repo is far more likely to go stale and 
>> bitrot.
>> Also, please note that the webUI has nothing to do with the website, it would
>> be the completely wrong place for it. The website is NOT hosted on the cloud
>> servers - these are completely different properties and I really don't want 
>> to
>> mix them. Life is hard enough as it is.
>> So while I'm of course open to people saying "this is different", I would 
>> claim
>> that this is simply a third UI. We have the QtWidgets UI (desktop), the QML
>> UI (mobile), and now the HTML UI that for technical reasons uses the CLI
>> to integrate with the Qt/C++ core of Subsurface.
> 
> I really like this, and agree with that interpretation.  When I first started
> using the planner, and really wished I could have it available when traveling
> without always carting a laptop around, one of the options I pondered was
> making a HTML UI for it - and this opens up some interesting new possibilities
> because once you have remote access to an instance, you also have the option
> of collaborative access to an instance.

So right now this is all implemented as READ ONLY.
But of course, that's just an implementation detail and all we need are new
commands in the CLI and corresponding UI elements in the webUI. So anyone
who feels strongly about any of this is certainly free to submit more pull 
requests.

BTW: I still haven't submitted a PR for the existing webUI as I want to play 
with
it a bit more. I keep seeing small things that bug me - it simply hasn't 
received
enough testing, yet.

> So you could do things like plan a dive, then have everyone on the team review
> it and be able to tweak it, without everyone needing to manually enter the 
> same
> data into their own devices or to crowd around a single device looking over
> someone's shoulder.

The authentication model for the cloud server is of course tied to a single 
email
address and wasn't intended for "shared credentials" (rarely a good idea) and
has no support (currently) for "multiple accounts access the same data" -- but
that, too, could be changed if there's enough interest.

/D
_______________________________________________
subsurface mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to