My favorite deco planner UI is Gue Deco Planner. I haven't used the new version 4, but I still run the old version 3 in wine. It's old and boring but runs just fine in wine.
The version 4 UI looks just the same as the old version 3, and version 4 just looks to be a modernised cross platform port. The biggest reason I like it is the simplicity, just look at: https://youtu.be/nRRGaddKwtc?t=458 Just a mobile UI which is that simple and shows me the tables as result would be just good enough for me =) //Anton On 19 April, 2023 - Vlad A via subsurface wrote: > Something like this. > > [image: Subsurface_UI_Mocup.gif] > > > On Wed, 19 Apr 2023 at 15:58, Vlad A <elf...@gmail.com> wrote: > > > 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. > > > > > -- > Thanks. > Vlad A. > _______________________________________________ > subsurface mailing list > subsurface@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface -- Anton Lundin +46702-161604 _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
