kossebau added a comment.
In https://phabricator.kde.org/D7194#160789, @leinir wrote: > This already went into one release, and it would be quite useful to get it sorted before the next one rolls around, and the consensus seems to be reverting, as leaving kns with this patch in has some fairly unfortunate side effects. Could we get it reverted before the next release is done? +1 The issues in Discover should hopefully be fixable by adapting to the explicitly-shared nature of the Entry* objects (famous non-maintainer/contributor words :) ). > The point about not reporting value changes is very much a good one, though - i think it would make plenty of sense to add that. It would be useful in any number of places (including e.g. in QtQuick, which obviously is my little baby, if we add it as properties... and it was sort of my mental todo anyway as something to do as i went ahead, unless anybody has large objections to me doing that). Most KNS classes have already separate signals to report about changes of entries they exposed (driven by KNSCore::Engine::signalEntryChanged), that possibly should be relied on or extended. There still might be issues across threads with that, but then EntryInternal/Entry objects might not be thread-safe anyway? Looking at the entry-object centric API though I wonder if it might not be better to turn for KNS4 to a usage with a central data model stored by the entry-maintaining model and consumers using indexes to query/set data when needed (seems entries are identifyable by provider + id). That would avoid creating lots of Entry* objects with duplicated data on every change of the data model and all the extra work by consumers to synchronize their copies of the Entry* objects they would maintain. REPOSITORY R304 KNewStuff REVISION DETAIL https://phabricator.kde.org/D7194 To: apol, leinir Cc: sitter, kossebau, whiting, mutlaqja, broulik, #frameworks
