Shouldn't we make the ApplicationWindow use the ApplicationItem instead of fully forking the code?

In D5166#97372, @apol wrote:

Shouldn't we make the ApplicationWindow use the ApplicationItem instead of fully forking the code?

I'm not sure it's possible, as it would change the parent/child relationships of contentItem/header/footer and a piece would need to be forked anyways as ApplicationWindow inherits from AbstractApplicationWindow and ApplicationItem inherits from AbstractApplicationItem

In D5166#99686, @leinir wrote:

i am inclined to ship this - there are the following couple of things which do show up, but the item works as expected anyway, and i now have a version of Calligra Gemini using Kirigami for a large part of its UI (there are details to be sorted as yet, including a not inconsiderable amount of UX reworking because of the old non-Kirigami-esque workflow design created by Cohere back in the day, but that is not caused by Kirigami, of course, and in particular not this item - so for the parts which are Kirigami-based now, it works :) )

file:///usr/share/calligragemini/qml/WelcomePage.qml:35:19: QML GlobalDrawer: cannot find any window to open popup in.
file:///usr/lib64/qt5/qml/org/kde/kirigami.2/AbstractApplicationItem.qml:306: TypeError: Cannot read property of null
file:///usr/lib64/qt5/qml/org/kde/kirigami.2/AbstractApplicationItem.qml:105: TypeError: Cannot read property 'drawerOpen' of null

yeah, i encounterd them.
unfortunately everything inheriting from QQC2 Popup will work kinda wonky under QQuickViews.. reparenting at the proper moment seems tough to make the thing still functional and just generate that warning