ideas for tasks before christmas

Lubomir I. Ivanov neolit123 at gmail.com
Tue Dec 3 13:59:23 UTC 2013


On 3 December 2013 23:30, Dirk Hohndel <dirk at hohndel.org> wrote:
> 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)?
>

from my understanding we have to estimate the percentage height and if
say the ratio was 200px for profile and 120px for table we have to fit
N columns, where a minimal height for a row is 12px, it means we can
only fit 10 rows, as the minimal row height is 12px - so "where would
the notes go" is the question. we already have a row minimum so this
is a bit tricky. in that row height we can fit safely a pixel height
font which is 9 pixels and looks OK on linux and win32 (tested),
without cutting out characters such as 'g' which have a under-tail
bellow the base line.

i can try making this work but i'm a bit concerned as currently the
font size in the profile starts to stack (overlaps) in the 1/6 print
and values are quite difficult to read out there.

from my POV, given the profile and table data on an A4 in a 1/6 print
(as this is the format i'm basing my work on) does not look that great
- a bit stacked with not much space for variations.

>> 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
>

slow, indeed. :(

> 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.
>

my machine is an i3 and slow in processing all the test dives already,
but i'm guessing we may have to move the layout calculations in a new
thread while updating the main thread (UI), with the progress bar
active while locking the UI for interaction, perhaps only leaving a
cancel button there.
i see this a definite improvement and i may work on that!

but tomaz pointed out that we may take a KDE (or something) print
dialog and modify it, in which area i'm a bit lost.
if we make a custom dialog then we can perhaps base such a work on it!

>> > 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 :-/
>

i can still help, but first i must understand the requirement.
...and will try to do so.

lubomir
--


More information about the subsurface mailing list