<table><tr><td style="">drosca added a comment.
</td></tr></table><br /><div><div><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>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.</p></blockquote>

<p>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 <tt style="background: #ebebeb; font-size: 13px;">maps.h</tt> with <tt style="background: #ebebeb; font-size: 13px;">QHash<quint32, Type*> + QVector<Type*></tt> 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.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>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?</p></blockquote>

<p>I guess it doesn't matter, but probably adding the getters + signals to Context will make the API simpler?</p></div></div><br /><div><strong>TASK DETAIL</strong><div><a href="https://phabricator.kde.org/T7994">https://phabricator.kde.org/T7994</a></div></div><br /><div><strong>To: </strong>drosca<br /><strong>Cc: </strong>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<br /></div>