On Tuesday 22 February 2011 11:28:35 Sebastian Trüg wrote: > Hi Chris, > > On 02/19/2011 01:39 PM, Christian Mollekopf wrote: > > On Saturday 19 February 2011 13:02:20 Vishesh Handa wrote: > >> The method Laura described is the correct one as of now. Though, we > >> would prefer it if you didn't use it. The reason is that you get > >> notified for all the statements that have been added/removed - and > >> those can be quite a lot. > >> > >> Especially if files or emails are being indexed. That causes the entire > >> system to slow down. I had to monitor everything for Nepomuk > >> synchronization, and it caused Nepomuk to slow down so much that in 4.6 > >> RC1, I finally had to disable it! > >> > >> We are working on a better way for you to watch changes in the Nepomuk > >> Repository. The current API that I have planned is something like this - > >> > >> ResourceWatcher * watcher = SomeObject->watchType( > >> Nepomuk::Vocabulary::NAO::Tag() ); > > > > what is SomeObject? > > > >> watcher would have its own statementAdded() and statementRemoved() > >> signals which would only give you those statements. I was even thinking > >> of watching by property. > > > > Yes, that would be good. > > > >> Would this solve your use case? Any comments on the API? None of this > >> has been implemented so feel free to comment - we can change anything > >> at this point. > > > > I have three usecases. > > > > Usecase1: > > Updating things like TagClouds where I need a signal when a new item of a > > certain type (i.e. Tag) is added/removed to/from the repository. For this > > the watchType with an added/removed signal for the concerned item would > > solve my problems. > > > > Usecase2: > > I filter a QAbstractItemModel based on the PIMO:isRelated property. > > So here I need a signal with the Resource and the changed isRelated > > property. > > > > Usecase3: > > When I display an item in an editor where I show some Nepomuk properties, > > I need a signal only for this exact resource. > > > > I'd like a similar api like the akonadi::monitor: > > > > > > > > //acts as a filter on the emitted signals for object type > > ResourceWatcher::watchType(Nepomuk::Vocabulary::NAO::Tag(), bool enable = > > true); > > > > //If set emits only signals for the explicitly watched resources > > ResourceWatcher::watchResource(const Nepomuk::Resource &, bool enable = > > true); > > > > //acts as a filter on the emitted signals for predicate > > ResourceWatcher::watchProperty(Nepomuk::Vocabulary::PIMO::isRelated(), > > bool enable = true); > > > > Usecase1: > > watcher->watchType(Nepomuk::Vocabulary::NAO::Tag() ); > > > > Usecase2: > > watcher->watchType(Nepomuk::Vocabulary::NAO::Topic() ); > > watcher->watchProperty(Nepomuk::Vocabulary::PIMO::isRelated()); > > So here you want to be notified of changes that involve the properly > pimo:isRelated and a subject of type pimo:Topic? In other words: > whenever a property pimo:isRelated is added to or removed from a > resource that has the type pimo:topic you want to be notified? > Basically yes, although It would be possible to make the group of monitored resources smaller.
I have an akonadi model filled with items, and I filter those items based on the nepomuk topic. So I need to emit dataChanged for the correct item if the topic has changed, so the filter is reevaluated. So I don't actually need to be notified for all resources in the storage but only a group of items. Maybe we could limit the resources by a custom mimetype or so? So far I do not set any mimetype on the resources I create, but this might be something which should be done? > > Usecase3: > > watcher->watchResource(res, true); > > //and maybe filtering for only the properties which im interested in > > > > I think that would keep us quite flexible and would be exactly what I'm > > looking for. > > > > Cheers, > > > > Chris > > > >> On Fri, Feb 18, 2011 at 5:25 PM, Laura Dragan <[email protected]> wrote: > >>> On Thursday 17 February 2011 16:32:45 Christian Mollekopf wrote: > >>>> Hey Laura, > >>>> > >>>> On Thursday 17 February 2011 14:10:58 Laura Dragan wrote: > >>>>> Hi Chris, > >>>>> > >>>>> On Thursday 17 February 2011 01:14:02 Christian Mollekopf wrote: > >>>>>> hi, > >>>>>> > >>>>>> Does anybody know how I can detect when a new Tag was added/removed > >>>>>> to/from Nepomuk? I.e. to update a Tag Cloud. > >>>>> > >>>>> do you need to update the tag cloud if any resource is tagged outside > >>> > >>> your > >>> > >>>>> app, or just inside your app? > >>>> > >>>> I'd like to update it whenever new tags are available, not only from > >>> > >>> within my > >>> > >>>> app. > >>>> > >>>>> In SemNotes for instance the tag cloud is built only with the tags > >>>>> used > >>> > >>> on > >>> > >>>>> the notes - you can find that code on gitorious. > >>>>> > >>>>> A long time ago I wrote a plasmoid that built the tagcloud for the > >>> > >>> entire > >>> > >>>>> desktop (not sure if it's in playground or not), and that one was > >>>>> listening to statementsAdded and statementsRemoved from the model, > >>>>> but > >>> > >>> I > >>> > >>>>> took the easy path and rebuilt the cloud every time instead of just > >>>>> updating it. It worked ok with up to 30 tags, without visible delays > >>> > >>> from > >>> > >>>>> all the repository querying. > >>>>> > >>>>>> Currently I listen to the statementAdded/statementRemoved signals > >>>>>> of > >>> > >>> the > >>> > >>>>>> Soprano::Model, and I can also detect if an Item gets a new Tag, > >>>>>> but > >>> > >>> I > >>> > >>>>>> don't know how I can see from the Statement when a new Tag was > >>> > >>> created > >>> > >>>>>> or a Tag was deleted. > >>>>> > >>>>> I think you can use the signals > >>>>> > >>>>> void statementAdded( const Soprano::Statement &statement) > >>>>> void statementRemoved( const Soprano::Statement &statement) > >>>>> > >>>>> to look into the statements that are affected with the functions: > >>>>> subject(), predicate() and object(). > >>>> > >>>> Thats what I'm trying to do, but I don't get what indicates that a tag > >>>> is > >>> > >>> new > >>> > >>>> to the Nepomuk system (or that a tag was removed). > >>> > >>> I'd do that by checking if the statement added or removed has the > >>> predicate "rdf:type" and the object "nao:Tag". The subject of the > >>> statement is then the uri of the tag that was created or deleted. > >>> > >>> Laura > >>> > >>>> Thanks for your help, > >>>> > >>>> Chris > >>>> > >>>>> Hope this helps > >>>>> Laura > >>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> Chris _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
