On Thu, 3 Nov 2011 11:10:03 Bache-Wiig Jens (Nokia-MP-Qt/Oslo) wrote: > > 1. No Widgets. Previously the window/menu stuff was providing QML > > wrappers around QWidget based classes, and the QWidget menu system. I > > never really wanted widgets in my QML anyways, but with the big split in > > Qt5 this seems even more like a necessary step. > > That is truly not really controversial at all. The reason we use widgets in > Qt4 is due to necessity. It is purely an implementation detail. The > QtQuick API should not in any way dictate a connection to QWidgets. We are > planning (but haven't gotten around to invest much work on it yet) To make > a new QAction/menu api that does not rely on Widgets at all.
Here's a suggestion for how that API could work. The new QAction replacement could be a QObject with the relevant properties (whatever QAction has that isn't forcing it to stay in QtWidgets really) and they form a tree on their own instead of attached to a QMenu* tree. A tree of QObjects is easy to specify and use in QML, and it would be quite feasible to create the parallel tree in QMenu* widgets for interoperability. It could even have convenience C++ methods like addSeparator to get a similar C++ API to before - just with the data model divorced from widgets. I have a prototype of this working in https://qt.gitorious.org/~aalpert/qt- components/aalperts-desktop-components again, and again it is not merged because I didn't bother with making it aesthetically acceptable. It's also not a good implementation, just a proof of concept. But it does validate that QObject* Lists/Trees are QML's simple data model. -- Alan Alpert Senior Engineer Nokia, Qt Development Frameworks _______________________________________________ Qt-components mailing list Qt-components@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt-components
