On Tuesday, July 03, 2012 20:55:45 [email protected] wrote: > Short note while on vacations... ;-) > > It was a conscious choice by me not to even try to split up QAction. > QAction is very much bound to widgets and I am not convinced at all it's > what we would need in QML. > > I think we would be better served in rethinking what is required for Qt > Quick and QML components and then try to figure out whether the class > should best live in QtGui, in QtQml or QtQuick.
... effectively making such a new QQuickAction or similar class not usable in hybrid applications. Hybrid applications using QtWidgets will use QAction, and if they want to integrate with QML they will have to export their QActions instead of using the new QQuickAction. It might be possible to make such a QQuickAction able to integrate with widgets, but no one ever claimed that was a goal. If it was a goal, then the API would be awful for BC reasons if done after 5.0. So where hybrid applications are used (presumably one of the things to aim for transitionally at least), we'll have two different and incompatible 'action' classes. That's not very appealing. I'm just pointing out the consequences of the choice, which I think belong with the statement of it. Thanks, -- Stephen Kelly <[email protected]> | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
