Hey Robert,
On Wed, 19 Apr 2023 at 06:32, Robert.Helling <atdo...@posteo.net> wrote:
> Vlad,
>
> > This construction is fool proof. You cannot confuse units. And it's
> readable in a glance. It's simple to do, but it will effectively nuke all
> .c files, cause you'll loose ability to use those units from plain C. So I
> guess it's not happening too soon.
>
> exactly. In fact, I think that last bit is an underestimate.
>
> Apart from that, I think one should not be too dogmatic: If stuff becomes
> too long, it is ok to use just ints for example for local variables not to
> be come too verbose as long as you know what you are doing and use good
> variable names that make it clear what that variable represents.
>
Eventually.
> >
> > Even right now, with the small changes I've got so far it has HUGE
> domino effect on a code base. I'll try to minimize the number of changes,
> but first submit will be kinda big.
> >
> > As of your last question about ideas which lead to all this in a first
> place. There's couple. Number one, and probably the biggest, is I would
> like to see planner working on mobile. Which might lead to big rethinking
> of UI. Editing profile the way we do right now in the planner will be a bit
> to much for a small screen. Also, you don't have all the widgets you have
> on PC.
>
> Of course, many people before had the idea to port the planner to mobile.
> But you are correct what is the major stumbling block: Design a reasonable
> UI that works with touch and without a keyboard but with limited screen
> estate. I don't think the world needs another dive planner with a million
> of scroll wheels to enter numbers for depths and durations which then,
> after pressing a "calculate" button produces a dive plan. That already
> exists. The Subsurface planner (in the desktop version) is different and
> from my point of view its main strength is the interactiveness, everything
> you change is immediately reflected in the dive plan (including when you
> drag waypoints with the mouse on the profile).
>
> I strongly believe that for a mobile planner the first step has to be to
> come up with a reasonable plan for a UI and possibly a mock up of it first.
> Hooking stuff up to calculations is then trivial in comparison.
>
> This is very doable. In fact I do have a layout in mind, which I believe
might work for smaller screen. You don't have to delete things, just
re-arrange it differently. Three sections:
1. Setup
2. Dive
3. Parameters
In vertical mode, you see pair. 1,2 or 2,3. This way, you always see "Dive"
section and ether have "Setup" above it, or "Parameters" bellow it. By
sliding up and down, you switch between sections.
In horisontal mode, you see one section with more details.
Now, each section can slide left and right independently of the other. So
it allow you to have more then one panel.
Here's how you can arrange them:
1. Setup
1. Presets for dives,
2. Gasses
3. Dive planer points,
2. Dive
1. Profile
2. Plan details
3. Parameters
1. Rates
2. Deco settings,
3. Gas options
4. Visualization options
5. Other options
Now, what that gives us? In that case, user always see a combination of two
things and since all "results" grouped in the second section and all inputs
are in first and second, you always have a pair of input / result on the
screen, so you aren't loosing interactivity. You can change something and
see result right away. Yes, you don't see everything at once, but you can
always slide stuff around and get stuff you want to change on one side of
the screen, and some visualization on other.
Most importantly, you're not loosing features and don't remove stuff. We
can fit everything we have right now into this layout and have some room to
extent it.
> > And some folks mention that they are afraid to use Subsurface planner
> cause it looks too overwhelming. This is something I personally disagree,
> but hey, there's that. If we can modify UI to make it a bit more
> approachable. I mean, presets, hide some stuff under some "Show advanced
> settings" checkbox, e.t.c.
>
> I agree that for a novice user the UI of the planner is far too baroque
> and has far too many handles and parameters. I would claim that that is
> just the optical impression and that most of that settings have sane
> default values and it is save to simply ignore most of them but that could
> definitely be presented to the user in a better way.
>
> But I would say, that is in the UI of the planner. That is neither
> planner.c nor deco.c but the stuff that is already in (Qt style) C++ like
> diveplanner.cpp and its friends.
>
Well, there's connection. Right now, the way those two things stores data
are fundamentally different. And sure, core part should be independent of
UI, but right now they're kinda independent both ways. UI cannot access
data from core directly, cause, reasons. So UI has it's own copy of data
and we have non-trivial way of synchronization in-between. UI cannot call
directly into core, you just run the planner and then UI use results. If
you need a change, you run planner all over again, an so on.
Example. What if I would like to add a feature, that shows the amount of
gas you need in case of emergency for any specific point of the dive right
under mouse pointer. No, for a second, lets drop the argument about: "Why
would you need it". It's an example.
The way I would see it, is that UI call the core, get me deco state for
point *t*, and then run ascent from there and then give me ascent gas,
e.t.c Simple, right?
Do we have all those functions? Yes we do? Can we call them this way? No we
cannot, cause those structures aren't flexible enough. They have to be used
and called in a very specific order otherwise things brake. This is exacly
why I started it. To brake the planner into smaller blocks so you can start
playing around.
--
Thanks.
Vlad A.
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
