KStandardActions needs KStandardShortcut which is in KConfigGui

Edit: Ah, I see this is tackeled with T12196

It also uses KI18n, although I have seen other frameworks using tr() instead to avoid KI18n, so maybe thats also possible here

Furthermore, it contains a ShowMenubarActionFilter class that uses Widgets and would thus block a move to *Gui. The class looks very questionable to me and has no external users

These are the things that would block a move to KGuiAddons:

• KStandardShortcut: could be moved to KGuiAddons after T12196
• KToggleAction: could be moved to KGuiAddons T14344
• KHamburgerMenu: KStandardAction::hamburgerMenu is new and seems unused so far
• KToggleFullScreenAction: Could be moved to KGuiAddons T14350
• KRecentFilesAction: To be replaced with KRecentFilesMenu from KWidgetsAddons. That cannot be moved to KGuiAddons though since QMenu is still in QtWidgets in Qt6. It's kind of an oddball in KStandardAction anyway since it's a menu and not really and action, so maybe we can leave it out. Then we need to make sure that KRecentFilesMenu does the shortcut stuff correctly on its own.
• KLocalizedString: Replace with qstr
• QLayout/QMainWindow/QMenuBar: Needed for ShowMenubarActionFilter. Solution: ?
• KAcceleratorManager: The whole class is very widget-based. Only KAcceleratorManager::addStandardActionNames is used though so maybe we can find a solution for that

Another data point, KStandardAction has some code like this:

if (pAction && parent && parent->inherits("KActionCollection")) {
    QMetaObject::invokeMethod(parent, "addAction", Q_ARG(QString, pAction->objectName()), Q_ARG(QAction *, pAction));
}

because it can't depend on KXmlGui, a tier difference issue, and (as Volker pointed out to me) it would be a cyclic dependency between it and KXmlGui.

This code is fragile, if those methods are renamed or there is a typo ...etc, no compile time checking, and you'd only find out there is an issue if you happen to start a app from terminal and read the messages printed there.