ideas for tasks before christmas

[Anton Lundin]

On 03 December, 2013 - Dirk Hohndel wrote:

> On Tue, 2013-12-03 at 23:20 +0100, Anton Lundin wrote:
> > On 03 December, 2013 - 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!
> > > 
> > > 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).
> > > 
> > > 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.
> > 
> > One reason its slow is because that the print code calls 
> > ProfileGraphicsView::plot, and that calls create_plot_info which
> > calls calculate_ndl_tts... 
> > 
> > And that doesn't even show up in the print.
> > 
> > A patch that disables prefs.calc_ndl_tts while generating the profiles
> > for print is incoming...
> 
> That patch is... awkward. But I admit that it works.
> And of course it makes no difference for people who have that turned
> off, anyway.
> 
> And even with it off, rendering my 270 or so dives takes quite a
> while...

With that patch it tok me about 2 seconds to generate print for the 35
test dives, 0.05s per dive, and about the same 0.05 per dive for my
whole logbook.

So, rendering for 10-15 seconds isn't anything uncommon, so a
progress bar would be great.

I think updating a progress bar from the for_each_dive in
PrintLayout::printProfileDives would e a simple way to go.

//Anton

-- 
Anton Lundin	+46702-161604