> -----Original Message----- > From: Development [mailto:development- > [email protected]] On Behalf Of Jedrzej > Nowacki > Sent: Friday, 26 February 2016 9:44 AM > To: [email protected] > Cc: Thiago Macieira <[email protected]>; Milian Wolff > <[email protected]> > Subject: Re: [Development] templated QObjects [was: Re: We are planning to > upgrade qdoc to use clang for parsing C++] > > 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 > > > > /d09c9 > > > > 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.
What about using C++ models in QML? QAbstractItemModel has to be a QObject for that reason alone. Often you also want to control the contents of the model by some UI-driven property in QML (e.g. a filter for a list of contacts based on a text input field). > 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 > > Cheers, > Jędrek > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
