On Thursday 11 December 2014 14:07:30 Marco Martin wrote: > On Thursday 11 December 2014, Martin Gräßlin wrote: > > > you mean it would still be possible to use qwindows as dialogs, but just > > > create them in a different way? > > > > yes > > ah, internal api... splendid > > > > > Any ideas how we could solve this problem? Could we make Dialog > > > > wrapping a QQuickWindow instead of inheriting it? Or are there better > > > > solutions? > > > > > > this may work, but could be a bit problematic since i guess a lot of qml > > > code expects it to expose the full qquickwindow api/properties, that > > > would all have to be wrapped > > > > That's what I would fear, too. It's certainly a lot of work and rather > > dangerous (hell we know all the problems dialog had) > > has kwin a single QQuickRenderControl ?
I'm not 100 % sure whether one can use one QQuickRenderControl for multiple windows. The API documentation is not clear about it, but there are signals like QQuickRenderControl::sync which do not carry for which scene it is, so I assume one needs to have one QQuickRenderControl per QQuickWindow. > could the following be done? > * register the QQuickRenderControl (or multiple ones by engine, if > necessary) in a some kind of singleton > * then Dialog would either call the normal superclass ctor or the one with > QQuickRenderControl if any was set That could work even if we need one QQuickRenderControl per window. It could be set as a magic context property "__org_kde_plasma_dialog_render_control"
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
