[Development] QAction-like API for QML

Stephen Kelly stephen.kelly at kdab.com
Tue Dec 18 13:24:59 CET 2012


On Monday, December 17, 2012 08:39:14 Alan Alpert wrote:
> On Sun, Dec 16, 2012 at 4:38 PM, Bache-Wiig Jens
> 
> <Jens.Bache-Wiig at digia.com> wrote:
> >>> What is so terrible about it? QtWidgetEnables would be private API, only
> >>> used by components internally and we would not need to load the module
> >>> on embedded, or am I missing something?>> 
> >> I don't see how you'd avoid loading the module on embedded. Because
> >> the components are written in QML you'd need the QtWidgetEnablers
> >> plugin available at runtime for any application using the components
> >> (assuming they include an import QtWidgetEnablers 1.0 line). I also
> >> don't know how you'd write the C++ module to avoid having a
> >> libQt5Widgets runtime dependency.
> > 
> > Well we have the same issue with components so we really have to find a
> > solution if we have any plans of making those widget independent in the
> > future. Embedded would be fine regardless since you could still ifdef
> > QT_NO_WIDGETS from your qtbuild before deployment.
> I thought the plan was to get away from all widget dependencies in the
> component set ASAP. The idea was that anything the component set
> needed which was still in widgets (but not widget-specific) would get
> abstracted out of widgets.

That's why it was a mistake to not extract a QGuiAction from QAction imo, but 
it's a mistake we have to live with and deal with as best we can (for both C++ 
and QML APIs).

Thanks,

-- 
Stephen Kelly <stephen.kelly at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121218/1e70e61c/attachment.sig>


More information about the Development mailing list