On Tuesday 22 February 2011 14:47:37 Sebastian Trüg wrote: > On 02/22/2011 11:48 AM, Christian Mollekopf wrote: > > 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? > > mimetypes are not the way to go. We only filter by type. > So a watcher would allow to specify a set of resources, a set of > properties, and a set of types where the following combinations make sense: > > 1. Only resources are set: > Signals about property changes of the configured resources and > deletion of the resources. > 2. Resources and properties are set: > Signals about property changes of the configured resources and the > configured properties. > 3. Only properties are set: > Signals for any property change that involves the configured > properties. > 4. Only types are set: > Signals about newly created or deleted resources of any of the > configured types. > (Possible variant via flag or whatever: Signals about property > changes for any resource of any of the configured types.) > 5. Types and properties set: > Signals about property changes for any of the configured properties > on any resource of any of the configured types. > > IMHO other combinations do not really make sense. > > Is this enough? Is something missing?
I reckon that is all that is needed. Cheers, Chris > > Cheers, > Sebastian > > >>> 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 > > _______________________________________________ > Nepomuk mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/nepomuk _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
