On 27.11.19 11:19, Friedemann Kleint wrote:
Hi,
as discussed on the change, there is not much one can do with the newly
introduced QGuiAction; it serves as a base class for QAction and
QQuickAction, The naming follows the Q(Gui)Application pattern.
> QMenu *menu() const;
> -> static QMenu *QMenu::menuForAction(QAction *action);
> void setMenu(QMenu *menu);
> -> static void QMenu::setMenuForAction(QAction *action, QMenu *menu);
This in my opinion is a no-go, we cannot do source-incompatible changes
in this area because there have been many deprecations already and code
needs to compile against 5 and 6 with minimal changes.
Ofc, having one QAction class in QtGui is desirable; but it must not
infer source-incompatible changes (and no, hacks like forward declaring
QWidget from QtGui or similar are also a no-go since it causes trouble
for Qt for Python).
You can keep the API as is in QAction in QtGui, and have the implementation in
QtWidgets:
in QtGui/qaction.h
// forward declare classes from QtWidget
class QMenu;
class QWidget;
class Q_GUI_EXPORT QAction {
// ...
// that's ok, the class is forward declared
void setMenu(QMenu *);
QMenu *menu() const;
}
// in QtGui/private/qaction_p.h
class Q_GUI_EXPORT QActionHooks {
public:
virtual void setMenu(QAction *, QMenu *) = 0;
virtual QMenu *menu(const QAction *) = 0;
// ...
static QActionWidgetsHooks *instance;
};
// in QtGui/qaction.cpp
void QAction::setMenu(QMenu *menu) {
if (!QActionHooks::instance) {
qWarning("QAction::setMenu: can only be used in a QApplication") ;
return;
}
QActionHooks::instance->setMenu(this, menu);
}
// in QtWidgets/qapplication.cpp
#include <QtWidgets/private/qwidgetsactionhook_p.h> // implements QActionHooks
void QApplication::QApplication(...) {
// ...
static const QWidgetActionHooks actionHooks;
QActionWidgetsHooks::instance = &actionHooks;
// ...
}
That's just an example, there is other ways to do it.
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
