On Freitag, 26. Februar 2016 09:43:40 CET Jędrzej Nowacki wrote: > On Thursday 25 of February 2016 19:22:55 Milian Wolff wrote: > > On Donnerstag, 25. Februar 2016 09:02:11 CET Thiago Macieira wrote: > > > On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam wrote: > > > > This might be a burden for some of the Qt developers (Windows ones). > > > > > > > > But all the Qt users get a modern / flexible moc, see this thread: > > > > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09 > > > > c9 > > > > 0e > > > > > > I don't think we need a more flexible moc. What do we want to do that we > > > can't do with the current one? > > > > > > Don't say "template QObjects". That has other reasons for being a bad > > > idea, > > > currently. > > > > Can you explain what those reasons are? I'd really love to write a generic > > QAbstractTableModel implementation that operates using concepts. Currently > > that would require type erasure and thus another set of virtual function > > calls... > > > > I.e. in many projects I end up writing the same boiler plate code to > > display a QVector<MyRowType> in a view. As far as I can see most of that > > could be abstracted away easily, leaving only slim concepts to the > > struct: > > > > struct MyRowType { > > QString foo; > > int bar; > > QVariant data(int column, int role) const > > { > > > > if (!role == Qt::DisplayRole) return {} > > switch (column) { > > > > case 1: return foo; > > case 2: return bar; > > > > } > > return {}; > > > > } > > }; > > > > this could easily be extended to other methods, such as setData, > > headerData, etc. pp. In the end, one would only need to implement a > > trivial minimal API at the place where the data is actually stored. And > > no, I do _not_ consider the current QAIM interface trivial to implement, > > not even for "simple" lists! > > > > If we'd have templates QObjects, the above could easily be written. I bet > > there are other valid use-cases. > > > > Cheers > > Hi, > > When first time I heard about templated QObject, QAIM was my first thought > :-) The thought evolved over last months and now I think that QAIM should > not be QObject at all, it is just an unnecessary cost.
Can you explain how you imagine the code to look like for the model to notify the view about changes? Curtis' note on QML requiring introspection for models is also very valid. > The main problems of templated QObject are captured more or less in this > thread: > http://lists.qt-project.org/pipermail/development/2013-March/010288.html > > Personally I still think it would be a fancy feature, a bit dangerous to > implement maybe even dangerous to use, but really cool :-D Thanks for the link. How often is the MOC layout changed in an ABI incompatible way? I.e. what problems would we get from having to install the moc files? Alternatively: couldn't moc re-create the required data from included files when they contain templated objects? That would solve the problem as well, no? Cheers -- Milian Wolff | [email protected] | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
