I'm working on rewriting KRun for this.
Current idea:
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T11547 Remove unneeded QWidget dependencies to set parent windows or display errors | ||
| Open | None | T12089 KIO for KF6 | ||
| Open | dfaure | T11549 KIO: remove unneeded QWidget dependencies to set parent windows or display errors | ||
| Open | dfaure | T11821 Move KDirModel to KioGui |
The next step (after CommandLauncherJob and ApplicationLauncherJob) is to port KRun::runUrl, which is called by "new KRun" once it knows the mimetype of the URL.
Problem: runUrl() will either run a command (ok), an application (ok), or ... display the "open with" dialog. What should happen in a non-widgets setup? Is someone going to write a QtQuick version of the open with dialog?
Well, either way I can do like in D29153 and define an interface which is used by a kiogui job and is reimplemented in KIOWidgets (and enabled by the use of KIO::JobUiDelegate). Initially: no widgets, no open-with dialog. If later someone wants to provide a QtQuick implementation, they can.
KRun is fully done.
KDirModel (with KDirLister and FileUndoManager) is on-going in T11821.
Core/Gui split for KUriFilterPlugin is handled in T14306.
Is KAbstractFileItemActionPlugin::actions a problem?
What about KFileItemActions::setParentWidget?
KIO::pasteClipboard? KIO::pasteMimeData?
KIO::ThumbCreator::createConfigurationWidget()/writeConfiguration()?
Is KAbstractFileItemActionPlugin::actions a problem?
What about KFileItemActions::setParentWidget?
QMenus needs a QWidget as a parent, see https://invent.kde.org/network/kio-extras/-/blob/master/activities/fileitemplugin/FileItemLinkingPlugin.cpp#L103 as an example.
I am unsure about how relevant the error reporting part is, because not the KAbstractFileItemActionPlugin have a proper feedback channel to report errors.
I don't think they /need/ a parent widget. For memory management purpose we can also pass a QObject in (or parent it to the QAction maybe?) . For windowing system purposes we can use QWindow instead
I don't think they /need/ a parent widget.
Without Qt changes, menu is maybe special case. There is a QWidget* parent in the qmenu exec methods.
This isn't just used to get a window, they do horrific things with casting the parent to see if this menu is a child of another menu or a menubar or something else. It also gets RTL from there.
See QMenuPrivate::topCausedWidget
That could still be solvable with KIO just passing it as an opaque pointer without needing to link widgets.
Is KAbstractFileItemActionPlugin::actions a problem?
QAction is be in QtGui in Qt6
What about KFileItemActions::setParentWidget?
Needs investigation
KIO::pasteClipboard? KIO::pasteMimeData?
is deprecated
KIO::ThumbCreator::createConfigurationWidget()/writeConfiguration()?
Is deprecated