Move QAction to QtGui

Qt Quick Controls had to make their own version of QAction, to not depend on QtWidget. We should have a generic one in QtGui (ditto QActionGroup). QActionEvent (handled by widgets is already in QtGui). There is also QWidgetAction providing virtuals for creating/removing custom widgets.

Should wait for https://codereview.qt-project.org/c/qt/qtbase/+/255770

Functionality

• Maintains a list of controls/widgets triggering the same , well, action
• For propagating enabled/state, checked, etc to the controls, QAction emits changed() and sends QEvent::ActionChanged via sendEvent
• Widgets have a list QWidgetPrivate::actions. QWidget::add/insertAction() adds them to the list and sends Event::ActionAdded, which the widgets handle to do the graphics setup and connections. Similarly for removeAction()
• To trigger, controls call QAction::activate(ActionEvent { Trigger, Hover }

  ); this handles checkable internally) from the list of their actions

• QAction::event(QEvent *e) catches keyboard shortcuts and triggers and calls activate()

Problematic API in QAction:

 QMenu *QAction::menu() const/QAction::setMenu(QMenu *menu);
QWidget *QAction::parentWidget() const
QList<QWidget *> QAction::associatedWidgets() const
QList<QGraphicsWidget *> QAction::associatedGraphicsWidgets() const
bool QAction::showStatusText(QWidget *widget = nullptr);

accesses

qWidgetShortcutContextMatcher

QActionGroup does not appear to have problematic dependencies.

Workshop 6/19 conclusion

QAction as such is pretty much tied to a list of controls (of some kind), so it does not make sense to move it as is into QtGui.

It is suggested to extract a class QGuiAction into QtGui which has virtuals operating on the controls (sendEventToControls/removeFromControls()), following the QGuiApplication naming scheme.

This would also minimize the porting hassle for widget applications.

It might be worth trying the same with QShortcut.