phonon5 and the descriptors

[Casian Andrei]

Hey,

2013/10/8 Harald Sitter <sitter at kde.org>

> 1) thinking of QML integration aforementioned almost-POD will probably
> have to be wrapped by a qobject to get sane code in QML, so should we
> perhaps make it a QObject to begin with? (this would give us a free
> property implementation but also increase the size of the objects in
> non-QML code, not by much but qobject/qmetaobject still adds a lot of
> cruft that we do not need)
>
 Without knowing any delicate details about the QObject internals, I would
go for having all the stuff derived from QObject, except some basic classes
that might be needed. /me likes signals, slots, q_property - worth the cost
for me.

>
> 2) right now all descriptions are derived from QSharedData (i.e. their
> dpointer is explicitly shared such that everything in the private
> object is not ever copied) which seems useful at first but considering
> that the private object basically only contains a qlist<qbytearray,
> qvariant> (where the QV is either qstring or int) it becomes somewhat
> weird. to me it seems rather pointless as the shared data is basically
> limited to  primitives (int) or already shared types (qstring) and it
> does not ever change after creation and I failed to find a use case
> where you would keep copying the objects around (also doesn't happen
> in any of the open source phonon applications). so qsharedata yay or
> nay?
>
If we get rid of qlist<qbytearay, qvariant> properties, we should get rid
of it for good, imo. Normal classes with normal members (pimpl mode) are
simpler and it makes it easier to discover them. And if there are no use
cases with lots of copies being made, then why bother with shared data? So
QSharedData nay for me.

My level of understanding is very general and a bit vague at this point, so
I'm thinking more on feelings than on technical experience here. So there
may be important facts that elude me :)

Cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20131008/30ac20a4/attachment.html>