[PATCH 0/5] Some steps to bring back printing support

[Lubomir I. Ivanov]

On 26 March 2014 02:02, Tomaz Canabrava <tcanabrava at kde.org> wrote:
>
>
> On Tue, Mar 25, 2014 at 6:47 PM, Lubomir I. Ivanov <neolit123 at gmail.com>
> wrote:
>>
>> On 25 March 2014 23:34, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>> > [PATCH 4/5] Print: enable printing with the new profile
>> >
>> > we again make the already active profile instance re-usable.
>> > as mentioned in the patch notes *weird* things happen if we try to
>> > create
>> > a local instance. the line colors spaz out on the main profile
>> > widget and the app crashes soon after.
>> >
>> > the main widget being affected leans towards singleton issues...
>> >
>> > the expense factor is not that impacting; even if the profile is
>> > a big class, i guess, i theory at least we can create a new instance
>> > for printing and let it drift out of scope, once done as you did in
>> > ac9a23ef3b69.
>> >
>> > also, i think there are some scalling issues related to the approach
>> > because the print scalling is based on the widget present on the screen
>> > and the screen DPI. if the widget is not part of widget stack some odd
>> > values are returned and i have no idea what is the cause FTM.
>> > the local instance profile's scale is quite off.
>> >
>>
>> here is a screenshot from current master (dd0c995f) that hints about
>> the possible singleton or memory corruption issues that i describe in
>> the above email.
>> http://imgur.com/T9DmnEz
>>
>> similar to the #478 report.
>
>
>
> This is most likely because when you create a new instance of the
> ProfileWidget and send a dive to it to be plotted , the C code that does the
> calculations for the dive info is deleting the old one ( the one that`s
> attached to the mainWindow)  - but we still keep the reference of it.
> One way to make that work is to not have globals to hold stuff, instead pass
> the plot_info as parameter. This is something that I need to do if I want to
> support showing more than one dive at the same time on the new profile, so
> it`s definitely on my TODO list.
>

i see,

these patches do fix the printing temporarily, by reusing the active
profile instance.
if you think these can go in for now, +1 this message.

the only thing that does not work is the grayscale switching (and in
that sense the B/W print).
if we are going to create a local instance of the class for printing,
i guess, the grayscale flag has to be passed to the profile
constructor or the profile should be able switch color on the fly (not
possible ATM).

also all the items need to use the [1] values from the color table as
most currently use the grayscale = false from getColor()

lubomir
--