GSoC - Customizable print formats

Tomaz Canabrava tcanabrava at kde.org
Sat May 30 13:39:35 PDT 2015


On Sat, May 30, 2015 at 4:33 PM, Lubomir I. Ivanov <neolit123 at gmail.com>
wrote:

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

I think grantlee needs the Q_PROPERTY
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.

The thumbs up rule is: your class don`t need signals and slots? it doesn`t
need to be QObject.
https://doc-snapshots.qt.io/qt5-dev/qobject.html#Q_GADGET


>
> lubomir
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150530/45094a93/attachment.html>


More information about the subsurface mailing list