SUMMARY KParts can't be embedded in Kirigami applications. KParts are one of KDE’s biggest selling points for developers, in my eyes - being able to reutilize GUI implementations of functionality like any CLI application would, as if the developer were using <iframes> in HTML. Few, if any, other frameworks provide this capability. EXPECTED RESULT I should be able to use KParts with Kirigami. ADDITIONAL INFORMATION https://discuss.kde.org/t/why-does-kirigami-overlaysheet-exist/13920/8?u=rokejulianlockhart
This is not feasible. Sorry.
(In reply to David Edmundson from comment #1) It looks to me like KParts are Qt's iFrame equivalent. What replaces them in Kirigami? I don't think most developers would mind learning to use a new technology, insofar as it provides equivalent capabilities.
Nothing replaces them in Kirigami.
(In reply to Nate Graham from comment #3) Do you have any insight about what you'll eventually do to replace the Konsole KPart inside DrKonqi and Dolphin, and the Dolphin KPart inside its myriad consumers? I imagine you don't want to keep them and their dependents as QtWidgets eternally, so perhaps I'm thinking about this incorrectly – X/Y.
If we eventually port these apps to QML or create QML competitors, of course KParts won't fit in there. But KParts is an implementation detail that in principle the user shouldn't care about; that's not really the right question to ask. Instead, the question is how to get embedded terminal views, file views, etc working; those are the things people want; the under-the-hood implementation is not so important. And it's not a problem to design QML-based library components for things like terminal views and file views that can be integrated into QML apps. Kparts is simply an older implementation of this kind of functionality that allowed it to be swapped out at runtime. That's not really a very important part, which is my reading of why the technology sort of got forgotten over time.
(In reply to Nate Graham from comment #5) Thanks. That's brilliant to hear.