[Kde-games-devel] KDE theme colors API for QML
Kevin Krammer
krammer at kde.org
Thu Aug 8 12:30:35 UTC 2013
On Thursday, 2013-08-08, Денис Купляков wrote:
> > I think it is also important to keep in mind that such a change effects
> > the usage pattern for a class considerably.
> >
> > KColorScheme is currently a value class, it can be copied, passed around
> > and stored without any concern for ownership.
> > A QObject derived class can not and is additionally bound to the thread
> > that created it.
> >
> > The easiest way might be to create an enum holder class that is
> > registered as an uncreatable type, i.e. just service as a namespace for
> > the enum(s). BlackBerry's Cascades framework does that a lot [1]
> > [1] LayoutOrientation is a class only holding a Type enum, used as the
> > value for a different' class' properties, e.g. StackLayout's orientation
> > property
> > https://developer.blackberry.com/cascades/reference/bb__cascades__stackl
> > ayout.html
>
> That way I think we need to rewrite all accesses to this enums around
> all code that use this enums, or I don't understand something??
I was under the impression that there is no QML related code (QML files or C++
adapter code) with those enums yet.
In case you are referring to C++ code that is currently using KColorScheme
enums, then no, that code can stay unchanged. Any QML adapter would simply
translate the values.
If the enums of the adapter are equal to the one of KColorScheme (which is
likely because this is the desired use), then "translating" is a simple cast.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-games-devel/attachments/20130808/4af3811a/attachment.sig>
More information about the kde-games-devel
mailing list