aloha
I am looking for some input regarding the future of objectdescriptions
in phonon5.
++
tldr: should objects describing a property/setting of phonon objects
such as Subtitle/AudioOutputDevice/AudioChannel be QObjects; if not,
should they be QSharedData considering they are comprised of
implicitly shared qt objects (e.g. qstring) and do not ever get
changed after creation.
++
right now objectiondescriptions are very generic descriptions for
devices, subtitles, audiochannels, chapters etc.
they essentially are a qlist<qbytearray, qvariant> where the QBA is a
property name the QV a property value. due to what they describe in
practise the QV is either a qstring or an int or qt container (e.g.
qlist) containing those types.
what we already concluded was that they should get more explicit API
to increase discoverability and general reliablity (due to
explicitness).
so instead of what we have right now:
SubtitleDescription {
int index
qstring name
qstring description
qvariant property(char*)
qlist<qbytearray> properties()
}
we would get something like
Subtitle {
int index
qstring name
qstring description
qstring language
auto encoding
qstring path /* null if not file based */
}
possibly still backed by a qlist<qbytearray, qvariant> but giving
explicit accessors to the properties.
Two questions arise though:
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)
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?
an additional note for QSharedData: phonon4 *publicly* implements the sharing
> class PHONON_EXPORT ObjectDescriptionData : public QSharedData {...};
> class ObjectDescription {
> ...
> QExplicitlySharedDataPointer<ObjectDescriptionData> d; };
IMHO that is wrong, the data class should be private and be held by a
ObjectDescriptionPrivate instance. if done that way we could
add/remove the sharedness at a later point.
.h:
class ObjectDescription {
ObjectDescriptionPrivate *d;
}
.cpp:
class ObjectDescriptionData : public QSharedData {...};
class ObjectDescriptionPrivate {
QExplicitlySharedDataPointer<ObjectDescriptionData> data;
};
HS
_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel
