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