On Sat, May 30, 2015 at 4:33 PM, Lubomir I. Ivanov <neolit...@gmail.com> wrote:
> On 30 May 2015 at 20:07, Gehad Elrobey <gehadelro...@gmail.com> wrote: > > > > > > On Wed, May 27, 2015 at 10:32 PM, Lubomir I. Ivanov <neolit...@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 > -- >
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface