GSoC - Customizable print formats

[Lubomir I. Ivanov]

On 30 May 2015 at 20:07, Gehad Elrobey <gehadelrobey at gmail.com> wrote:
>
>
> On Wed, May 27, 2015 at 10:32 PM, Lubomir I. Ivanov <neolit123 at gmail.com>
> wrote:
>>
>> 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.
>>
>
> fixed and pushed, I also removed the new print dialog and modified the
> existing one as discussed, and merged the patch you have sent before.
>

ok, i will take a look tomorrow.

>>
>> 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.
>>
>
> May you please clarify this more as I thing I am missing something, I had a
> quick look on ProfilePrintModel and what I understand that I have to create
> a new model for printing, and connect it with the existing diveitem to reuse
> the existing code, The new class will be responsible for formatting the dive
> fields to the templating Engine, that's all right?
>

ok, here is what we are going to do.

Tomaz has separated the models into separate cpp/h files, which is great.
but profileprintmodel.* and tableprintmodel.* are obsolete, so please
remove them in a new patch.

it's probably best to keep your Dive class for now and use helpers.h
to provide correct display for use selected options e.g. F vs C, ft vs
m, kg vs lbs and so on.

my idea from above was the following - we don't need DiveItem as your
"Dives" are not going to be "Items" in a "View " (think about the
Model-View-Controller pattern that Qt uses, which i dislike with a
passion), we just need the formatting it provides and the fact that
the QTableView already has allocated the DiveTripModel and all the
DiveItems (i.e. all the dives are on display in the dive list). but
this gets a bit complicated to tackle, so let's use the Dive class for
now...we may improve this eventually and make the memory more
re-usable.

one question, can your Dive class avoid subclassing QObject?
QObject is heavy, can we just use a standard C++ class without the Qt
Q_PROPERTY members?

lubomir
--