On 18 December, 2014 - Willem Ferguson wrote: > On 18/12/2014 03:27, Tomaz Canabrava wrote: > > > Tomaz, > > If it's possible at all, we need to complete the CCR UI. Would you be > prepared to help, please? I have been messing around with private branches > of the code that are rapidly ageing but my understanding of the Qt code is > pathetic. We need: > a) Graph of setpoint data when the pO2 is shown on the profile. > b) A graph that displays all the data from the individual oxygen sensors > with respect to the setpoint. > I would so much like to get this part of the development behind us in order > to get on with the other CCR systems. >
I don't know if we actually should try to jam this into the profile to. I'm guessing a separate ui to analyze the o2-cells would be better. My suggestion is just to grab paint/gimp/whatever and mock how you think the ui should look and work. > Extension of the present code to accommodate APD logs will not be cosmetic, > but very easy, now that a basic infrastructure exists: problem there is 2 > parallel dive computers. > The APD development is not likely to have UI consequences, or, if at all, > minor consequences in the manner of selecting APD logs in the import panel. > I did some experimenting on this and my plans where to just import C1 and C2 ans different dive computers, just running the csv-import twice. I got de-railed trying to cleanup the spagetti surrounding the csv-import... //Anton > >Em 17/12/2014 20:48, "Robert Helling" <[email protected] > ><mailto:[email protected]>> escreveu: > >> > >> … what are people planning to spend time on? > > > >Unit tests, since 4.0 I keep saying that. > >Speed improvements in the profile. > >Printing improvements > >Publish on ( Facebook, gplus) > >Dropbox, Facebook, integration for images > >Git ui. ( I just need to know how it's supposed tô look like) > > > >> For me that would be (not necessarily in that order) > >> > >> 1) pSCR (as just explained in a different mail) > >> > >> 2) Making image integration more portable between the devices, in a way > >to be determined: paths relative to a (configurable) image_root, relative > >paths from home etc, images from the web… We talked about this before. > >> > >> 3) Increasing responsiveness of the planner (doing some profiling, maybe > >splitting the replot into smaller tasks that not all need to be redone > >upon changes of data etc) > >> > >> And of course there is the big elephant in the room (but I probably > >cannot really contribute due to lack of ideas/understanding): Coming up > >with a UI to utilize the git save/load. > >> > >> Other ideas? > >> > >> Best > >> Robert > >> > >> _______________________________________________ > >> subsurface mailing list > >> [email protected] > ><mailto:[email protected]> > >> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface > >> > > > > > > > >_______________________________________________ > >subsurface mailing list > >[email protected] > >http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface > > _______________________________________________ > subsurface mailing list > [email protected] > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface -- Anton Lundin +46702-161604 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
