ideas for tasks before christmas

[Dirk Hohndel]

On Tue, 2013-12-03 at 23:21 +0200, Lubomir I. Ivanov wrote:
> On 3 December 2013 22:49, Dirk Hohndel <dirk at hohndel.org> wrote:
> > A) printing. printing. printing.
> >
> > There are so many ways to make this better.
> > End goal would be something with templates, but if you could just
> > something where for the 6up print the relative height of text and
> > profile can be modified within reason. The profile is cool and
> > everything, but most people will want to be able to make it small enough
> > to have all of the notes printed...
> >
> 
> this is quite hard at the moment and the main fault is exposure to
> high level interfaces (e.g. in Qt and lack of templates).
> we can enable proportional sizing of profile against table, but that
> will not solve things much as we still have to estimate a number of
> rows for the table.
> honestly, the current table height is quite optimal for the 6print as
> getting a row any smaller or the font any smaller breaks the text
> visual!

So right now we have 1/6th of the page and that gives us a fixed height.
Can't we change the percentage of that height that is available for the
profile vs. table (including notes)?

> i'm a bit out of ideas on this one...
> in terms of layout, perhaps we should consider an external format
> export where the user can decide the layouting and optional print
> parameters himself (like SAC in a specific cell, rating...etc). this
> is quite demanding by the user and difficult to implement.
> also, this has been discussed before and i think external tools are
> the way to go, even if it's subsurface triggered (i.e. a menu entry,
> somehow).

I don't think we need to be THAT flexible. But who knows.

> if external tools are not an option i'm thinking of a premature idea
> where the user can draw the table (e.g.) in ASCII with some predefined
> constants and then we can draw that with Qt's drawing engine, but that
> may be MUCH slower that the current implementation.

And that's already slooooow

Which reminds me.

Make item (A-1) please "add progress bar to print rendering". Right now
it looks like the application is hung while you prepare to print all
dives (assuming you have a few hundred dives).

BTW, do you have a decently sized XML file to play with? I'll be happy
to share my XML file if that would help. That will give you an idea
regarding the notes issue, too.

> > B) native building under Windows
> >
> > I know you have that mostly working. Having this documented well enough
> > that someone else could install the same tools and libraries and retrace
> > your steps to get to a working build would be helpful.
> >
> 
> i've already provided quite a bit of information on this topic in the
> readme, but only one person has asked me for details in a couple of
> months, which means there is no interest.

I for one am interested. But following your suggestions I couldn't get
it to work and gave up (ran out of time).

But you may be right - maybe it isn't that many people.

> building on Win32 is not easy because pkconfig is broken and there is
> the lack good library maintenance.
> it's really for experienced Win32/Linux programmers, i would think.
> (discussed many times already)
> 
> i really think we should drop this for now unless more people have the
> request for guidelines.

Ok, I can accept that.

> > C) turn the profile preparation calculation into a two pass thing
> >
> > i.e., first calculate JUST the profile, tank pressure, partial pressures
> > (and allow the drawing to start once that is done), then do all the
> > other calculations (deco, TTS, etc)
> >
> > That last one will need some coordination with Tomaz who wants to
> > reimplement the profile stuff, anyway
> >
> 
> i will have to investigate into that, since when i see deco and tank
> pressure i slightly "scatter".
> if i see tomaz making initial commits on this one, i can perhaps take
> over to make the final implementation.
> the drawing itself in Qt is not of much concern for me; what has to be
> drawn in terms of diving date is mostly issue. :(

Well, I don't think you really need to understand the dive aspects of
what "deco" or "tts" mean in order to put that in a separate thread and
have the UI provide no data until that thread has finished...

Let's discuss this with Tomaz and see what he thinks. Maybe we should
wait until after 4.0.

Which means you are stuck with just the printing ideas :-/

/D