> But if you are writing a 100% declarative UI you'd probably wish to > avoid linking against widgets. So I guess you're saying regular old > QActions should be exposed just for putting a declarative UI onto > legacy apps, and also there should be a new QQuick action, which is an > unrelated class?
Yes. That is exactly what I am proposing. We will support the parts of QAction that we can for legacy and portability, but we will introduce a new QQuickAction class for QML. You can use both with QML but you can only (directly) use QAction with widgets. >> I know that we can _force_ QML ActionGroup into becoming a visual >> description of a Menu but I don't get why that is a god idea. Menu is >> already an abstraction designed to describe a menu. Remember that in >> widgets, QActionGroup as a concept that is more similar to what we called >> CheckableGroup on Meego components. It does not at all indicate proximity or >> visual representation. > > Then I guess you don't place much value on reducing verbosity in QML. Not if it means making the API worse. I will not repeat the arguments here. > If you create the actions in C++, you'd still have to repeat each and > every one in QML, unless we provide a way to iterate over the ones > that should be in a menu, or a toolbar. How about having ToolBar.addAction() for convenience? It is exactly what we do for widgets. >> Sure. But we don't actually have support for logical icon names on Windows, >> Mac or Embedded since we don't have pixmaps for those. > > I'm not sure what you mean. This is really sidetracking the discussion but Windows and Mac do not have default action icons built-in and we do not ship those icons with Qt. There are practical and legal reasons for that. Most apps probably don't want to carry the extra data. Jens _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
