<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 30, 2015 at 4:33 PM, Lubomir I. Ivanov <span dir="ltr"><<a href="mailto:neolit123@gmail.com" target="_blank">neolit123@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 30 May 2015 at 20:07, Gehad Elrobey <<a href="mailto:gehadelrobey@gmail.com">gehadelrobey@gmail.com</a>> wrote:<br>
><br>
><br>
> On Wed, May 27, 2015 at 10:32 PM, Lubomir I. Ivanov <<a href="mailto:neolit123@gmail.com">neolit123@gmail.com</a>><br>
> wrote:<br>
>><br>
</span><span class="">>> well, having the code as WIP in master without the macro makes our life<br>
>> easier.<br>
>> i think we can live with the fact the GSoC will introduce a lot of<br>
>> changes, and we don't really want to #ifdef everything new.<br>
>><br>
><br>
> fixed and pushed, I also removed the new print dialog and modified the<br>
> existing one as discussed, and merged the patch you have sent before.<br>
><br>
<br>
</span>ok, i will take a look tomorrow.<br>
<span class=""><br>
>><br>
>> i have something else in mind, which may trigger some model.h changes.<br>
>><br>
>> models.h is the correct place to add the class (for now), but it<br>
>> should not be a model but rather an DiveItem based class, or something<br>
>> similar.<br>
>> as you may have noticed DiveItem and TreeItem really think in terms of<br>
>> Qt widgets (rows, columns, roles) and we don't really need that. we<br>
>> just need a wrapper class like your Dive class in templatelayout.h,<br>
>> but it will also need some of the already present code...<br>
>><br>
>> a goal here would be to have object oriented translation targets (e.g.<br>
>> less tr() calls) and unified text formatting logic (same formatting on<br>
>> the UI, hard copies and so on).<br>
>> this may require that we separate the formatting logic in DiveItem<br>
>> from the actual Qt widget *Item logic.<br>
>><br>
>> ProfilePrintModel::data() is a good example where DiveItem is used as<br>
>> temporary object because of it's complicated formatting output (e.g.<br>
>> di.displayDuration()). using this provides the same duration logic for<br>
>> the UI and the hard copy, yet the DiveItem is not really used as a Qt<br>
>> widget item, but rather just as a formatter class.<br>
>><br>
><br>
> May you please clarify this more as I thing I am missing something, I had a<br>
> quick look on ProfilePrintModel and what I understand that I have to create<br>
> a new model for printing, and connect it with the existing diveitem to reuse<br>
> the existing code, The new class will be responsible for formatting the dive<br>
> fields to the templating Engine, that's all right?<br>
><br>
<br>
</span>ok, here is what we are going to do.<br>
<br>
Tomaz has separated the models into separate cpp/h files, which is great.<br>
but profileprintmodel.* and tableprintmodel.* are obsolete, so please<br>
remove them in a new patch.<br>
<br>
it's probably best to keep your Dive class for now and use helpers.h<br>
to provide correct display for use selected options e.g. F vs C, ft vs<br>
m, kg vs lbs and so on.<br>
<br>
my idea from above was the following - we don't need DiveItem as your<br>
"Dives" are not going to be "Items" in a "View " (think about the<br>
Model-View-Controller pattern that Qt uses, which i dislike with a<br>
passion), we just need the formatting it provides and the fact that<br>
the QTableView already has allocated the DiveTripModel and all the<br>
DiveItems (i.e. all the dives are on display in the dive list). but<br>
this gets a bit complicated to tackle, so let's use the Dive class for<br>
now...we may improve this eventually and make the memory more<br>
re-usable.<br>
<br>
one question, can your Dive class avoid subclassing QObject?<br>
QObject is heavy, can we just use a standard C++ class without the Qt<br>
Q_PROPERTY members?<br></blockquote><div><br></div><div>I think grantlee needs the Q_PROPERTY</div><div>but you don`t need to subclass QObject and put the Q_OBJECT macro on those anymore ( this was mandatory in Qt4 ), because of QML, qt had to come with a lighter way to create properties, it`s the Q_GADGET.</div><div><br></div><div>The thumbs up rule is: your class don`t need signals and slots? it doesn`t need to be QObject.</div><div><a href="https://doc-snapshots.qt.io/qt5-dev/qobject.html#Q_GADGET">https://doc-snapshots.qt.io/qt5-dev/qobject.html#Q_GADGET</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
lubomir<br>
--<br>
</blockquote></div><br></div></div>