GSoC - Customizable print formats

Lubomir I. Ivanov neolit123 at gmail.com
Wed May 27 13:32:21 PDT 2015


On 27 May 2015 at 20:09, Gehad Elrobey <gehadelrobey at gmail.com> wrote:
>
>
> On Tue, May 26, 2015 at 12:55 PM, Lubomir I. Ivanov <neolit123 at gmail.com>
> wrote:
>>
>> On 25 May 2015 at 21:26, Gehad Elrobey <gehadelrobey at gmail.com> wrote:
>> > Hello Lubomir,
>> >
>> > As GSoC coding period have begun, I wanted to update you with my
>> > progress
>> > till now, I've pushed some more commits to my git branch, I will push
>> > some
>> > more commits on the weekend as I am having my finals exams now. BTW Have
>> > you
>> > managed to build subsurface with Grantlee yet or you still getting the
>> > same
>> > linking error?
>> >
>>
>> alright, i'm able to build now.
>>
>> please, merge the attached patch into your repository and let me know
>> if you have any issues with it.
>> also remove the NEW_PRINTING macro and CustomPrintDialog (more comments
>> bellow).
>>
>> per-commit short reviews. read from bottom to top:
>>
>> ---------------
>>
>> 9b2701e Add Progress bar to custom print dialog
>>
>> see da5ce64
>>
>> 3a37e57 Remove unused variable
>>
>> should be rebased. the code which it touches is WIP.
>>
>> ff97353 Open custom print dialog if NEW_PRINTING is defined
>>
>> see da5ce64
>>
>> da5ce64 Create the new custom print dialog
>>
>> i think you should just modify the current print dialog. adding more
>> files creates noise.
>> it was already discussed that master will have a "broken" printing
>> module while this GSoC task is WIP.
>>
>
> I though that I ll have to use the macro until the printing work is finished
> so that we can continue building subsurface without breaking the current
> module, I ll fix this.

well, having the code as WIP in master without the macro makes our life easier.
i think we can live with the fact the GSoC will introduce a lot of
changes, and we don't really want to #ifdef everything new.

>> 78fcd53 Add TemplateLayout class
>>
>> asked the same before; any comments on why we need a local Dive object?
>> i highly doubt this will reach master as is.
>
>
> I needs the local dive object as Grantlee::Context is initialized by
> QVariantList<Dive> which contains all selected dives information, I have
> also checked the existing dive class at "models.h" and the class was missing
> many fields that will be needed by the printing module, AFAIK the class in
> models.h is currently used in the dive list view only.
>

i have something else in mind, which may trigger some model.h changes.

models.h is the correct place to add the class (for now), but it
should not be a model but rather an DiveItem based class, or something
similar.
as you may have noticed DiveItem and TreeItem really think in terms of
Qt widgets (rows, columns, roles) and we don't really need that. we
just need a wrapper class like your Dive class in templatelayout.h,
but it will also need some of the already present code...

a goal here would be to have object oriented translation targets (e.g.
less tr() calls) and unified text formatting logic (same formatting on
the UI, hard copies and so on).
this may require that we separate the formatting logic in DiveItem
from the actual Qt widget *Item logic.

ProfilePrintModel::data() is a good example where DiveItem is used as
temporary object because of it's complicated formatting output (e.g.
di.displayDuration()). using this provides the same duration logic for
the UI and the hard copy, yet the DiveItem is not really used as a Qt
widget item, but rather just as a formatter class.

Tomaz does that sound good to you?

lubomir
--


More information about the subsurface mailing list