T7994: Extract Qt Pulseaudio bindings into a Framework
David Rosca
noreply at phabricator.kde.org
Thu Mar 29 09:33:54 UTC 2018
drosca added a comment.
> I was trying to get rid of the maps.h by replacing it with a QMap, but it proved tough. Is there any reason for the API user to know the indices? If not, a QList should be sufficient.
We need the indices, so if we expose it in API as anything else, we will need to hold and update two duplicated containers (QMap + QList) - in this case I prefer QVector instead of QList. Actually maybe we can replace the whole `maps.h` with `QHash<quint32, Type*> + QVector<Type*>` and get the same functionality out of, that QVector we need for public API and also better complexity (eg. constant index access instead of linear as it is currently). I'll try to implement this now.
> Should we create a new Type XMap that combines a QMap<quint32, X) with signals or just provide a QMap<quint32, X> and signals Xadded/Xremoved in context?
I guess it doesn't matter, but probably adding the getters + signals to Context will make the API simpler?
TASK DETAIL
https://phabricator.kde.org/T7994
To: drosca
Cc: davidedmundson, michaelh, akrutzler, apol, sitter, drosca, #kde_connect, nicolasfella, ragreen, adeen-s, SemperPeritus, ahmedbesbes, daniel.z.tg, jeanv, ZrenBot, seebauer, ngraham, bugzy, MayeulC, menasshock, lesliezhai, ali-mohamed, jensreuterberg, ach, abetts, sebas, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20180329/2467b6aa/attachment.html>
More information about the KDEConnect
mailing list