On 11/01/2010 10:53 AM, Amir Pakdel wrote: > Hi Sebastian, > > Thanks for your reply. > > On Mon, Nov 1, 2010 at 12:43 PM, Sebastian Trüg <[email protected]> wrote: >> Hi Amir, >> >> funnily enough you do exactly what was explained in "You are doing it >> wrong"[1]: you are trying to move the thread to itself. This, however, >> it not possible since the thread you want to move it to is not running >> yet (and for another reason that I forgot). >> >> Also the run method is called in the new thread. There is no need to >> start anything async in there. Just do the work, ie. what doUpdate() >> does now. > > I did it async because I wanted to queue up save requests and save > only once when a duplicate save request is encountered in the queue. I > will correct this issue and commit a new version. > >> >> "basketRes.setProperty( Soprano::Vocabulary::RDF::type(), >> Soprano::Vocabulary::PIMO::Note() );" >> this will overwrite all other types. You can just remove that line. > > Shouldn't I use "noteRes.addProperty"?
nope, you are doing addType in the line before. That is enough. :) >> >> "basketRes.setProperty( Soprano::Vocabulary::NIE::url(), basketUri );" >> No need. This is done internally anyway. >> >> "basketTag.setProperty( Soprano::Vocabulary::NAO::prefLabel(), tagName );" >> just use setLabel() >> >> >> Are you using nie:isPartOf to group subnotes? If so better use >> pimo:isPartOf. > Do you mean pimo:partOf ? [1] yes. Cheers, Sebastian > Thanks again, > Amir > > [1] > http://www.semanticdesktop.org/ontologies/2007/11/01/pimo/#partOf >> >> Cheers, >> Sebastian >> >> [1] >> http://labs.trolltech.com/blogs/2010/06/17/youre-doing-it-wrong/#more-1608 >> >> On 10/29/2010 09:25 PM, Amir Pakdel wrote: >>> Hi everybody, >>> >>> Dear Matt, >>> I have made some improvements (new features and bug fixes) to the >>> Nepomuk Integration and revised and resubmitted the merge request. >>> >>> >>> Dear Sebastian, >>> I have implemented "Indexing Contents of the Actual Notes" as following: >>> 1. Requesting nepomukstrigiservice (via DBus) to index the basket >>> folder (using indexFolder method). >>> 2. Connecting to indexingStopped signal. >>> 3. Cleaning up the mime-type when received indexingStopped signal. >>> This way, it even works on my older KDE 4.4.3 at work :) >>> would you please take a look at the source code on the following URL: >>> http://gitorious.org/~pakdel/basket/pakdels-basket/blobs/master/src/nepomukintegration.cpp >>> >>> >>> Dear developers, >>> I have used threading in the Nepomuk Integration and I will be >>> grateful if you could check my code :) >>> http://gitorious.org/~pakdel/basket/pakdels-basket/blobs/master/src/nepomukintegration.cpp >>> >>> >>> Thanks, >>> Amir >>> >>> On Sat, Oct 23, 2010 at 12:36 PM, Amir Pakdel <[email protected]> wrote: >>>> Hi Sebastian, >>>> >>>> On Fri, Oct 22, 2010 at 5:18 PM, Sebastian Trüg <[email protected]> wrote: >>>>> Hi Amir, >>>>> >>>>> On 10/19/2010 01:51 PM, Amir Pakdel wrote: >>>>>> Two more ideas came into my mind: >>>>>> 1. Something could be added to anthologies that indicates the priority >>>>>> of mime-types, like the "priority" property of "magic" XML element >>>>>> that is used in the XML files that define mime-types. This way, >>>>>> multiple mime-types of a resource can be prioritized. >>>>> >>>>> I think this is a problem with the way mime types are represented today: >>>>> as strings. Do you think a hierarchy of mime types would solve that >>>>> problem, too? >>>>> >>>> I do think so, because we can have things like the priority of the >>>> mime type, preferred application that handles a mime type and the >>>> application that added this mime type into the properties of the >>>> resource (the application that indexed the resource as a specific mime >>>> type). >>>> >>>>>> 2. Nepomuk::Indexer could have a method to set a flag in resources >>>>>> that prevents "automatic indexing" or at least prevents resources from >>>>>> being indexed using strigi, or some thing like a "lock" or a "do not >>>>>> change" hint or so. This way, a specific application would take full >>>>>> responsibility for the resource. Moreover, indexFile, indexResource >>>>>> and other method could have another parameter "force" that defaults to >>>>>> false and the application that is responsible for the resource could >>>>>> call these methods with force=true >>>>> >>>>> this is an interesting idea. How could we put that in RDF? Maybe a >>>>> simple property on the indexing graph which states the application >>>>> handling this specific file? >>>>> >>>> That is a good idea; the simpler the better :D >>>> This way, Nepomuk should check the application that is invoking the >>>> indexFile or indexResouce methods. Is it easy to implement? >>>> Therefore, when invoking application does not match the application >>>> name stored in RDF, it has to force the index. >>>> >>>> Cheers, >>>> Amir >>>> >>>>> Cheers, >>>>> Sebastian >>>>> >>>>>> >>>>>> I hope I explained my ideas intelligibly :D >>>>>> >>>>>> Cheers, >>>>>> Amir >>>>>> >>>>>> On Mon, Oct 18, 2010 at 5:06 PM, Sebastian Trüg <[email protected]> wrote: >>>>>>> Sounds like a good idea. However, I will still find a more generic way >>>>>>> in addition to that. >>>>>>> Stay tuned for more info. >>>>>>> Cheers, >>>>>>> Sebastian >>>>>>> >>>>>>> On 10/15/2010 07:38 PM, Amir Pakdel wrote: >>>>>>>> Hi Sebastian, >>>>>>>> >>>>>>>> On Fri, Oct 8, 2010 at 12:00 PM, Sebastian Trüg <[email protected]> wrote: >>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>> On 10/07/2010 09:25 PM, Amir Pakdel wrote: >>>>>>>>>> Hi everybody, >>>>>>>>>> >>>>>>>>>> On Wed, Oct 6, 2010 at 8:47 PM, Stephen Kelly <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>>> Matt Rogers wrote: >>>>>>>>>>> >>>>>>>>>>>>> The second solution is more appealing, but I would rather get a >>>>>>>>>>>>> working version with what we have got now. Therefore, I will go >>>>>>>>>>>>> with >>>>>>>>>>>>> the first suggestion. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> We actually have thought about interfacing with Akonadi for data >>>>>>>>>>>> storage/caching. If we do that, would we get Nepomuk integration >>>>>>>>>>>> for >>>>>>>>>>>> "free" as well? >>>>>>>>>>> >>>>>>>>>>> Just an FYI about this: >>>>>>>>>>> >>>>>>>>>>> I changed how kjots stores data so that it can use Akonadi for >>>>>>>>>>> access to the >>>>>>>>>>> notes. >>>>>>>>>> >>>>>>>>>> Although I have read all I could find about Nepomuk and Akonadi, I >>>>>>>>>> still don't know what Akonadi does exactly and how it interacts with >>>>>>>>>> Nepomuk! >>>>>>>>>> Could anyone please help me with that? >>>>>>>>> >>>>>>>>> AFAIK Akonadi stores blobs of data and provides a few APIs to convert >>>>>>>>> these blobs into something useful. One prominent example is mime data. >>>>>>>>> Nepomuk is a graph of information and thus, completely different. >>>>>>>>> Akonadi more or less duplicates all its information in Nepomuk so one >>>>>>>>> can perform searches on the data and create relations. This is a weird >>>>>>>>> situation as the info is stored twice but we cannot change that at the >>>>>>>>> moment. Maybe in the future we can merge both projects - who knows. >>>>>>>>> >>>>>>>>> So to me it does not make much sense to store notes in Akonadi as you >>>>>>>>> need to copy them to Nepomuk anyway. Thus, you would need to implement >>>>>>>>> the data handling twice: once the Akonadi blob and once the Nepomuk >>>>>>>>> resource data. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://dot.kde.org/2010/02/17/kjots-takes-advantage-innovations-kde- >>>>>>>>>>> development-platform >>>>>>>>>>> >>>>>>>>>>> KJots accesses the notes as Mime documents (KMime::Message objects) >>>>>>>>>>> from >>>>>>>>>>> Akonadi. Akonadi stores the notes in mime format in maildir >>>>>>>>>>> containers (one >>>>>>>>>>> note per file). The mime format could also be used to store the >>>>>>>>>>> images in >>>>>>>>>>> the note directly in the note, but I haven't got around to doing >>>>>>>>>>> that >>>>>>>>>>> (though there is API for it I think). >>>>>>>>>>> >>>>>>>>>>> http://www.faqs.org/rfcs/rfc2387.html >>>>>>>>>>> >>>>>>>>>>> The way Akonadi stores the notes is irrelevant to the application. >>>>>>>>>>> They >>>>>>>>>>> could just as easily be in mbox format (one single file for a group >>>>>>>>>>> of >>>>>>>>>>> notes). The application just uses the KMime::Message objects that >>>>>>>>>>> Akonadi >>>>>>>>>>> returns. >>>>>>>>>>> >>>>>>>>>>> Even if you don't make basket use Akonadi yet it could make sense >>>>>>>>>>> to store >>>>>>>>>>> the notes as mime messages and use KMime to (de)serialize them. >>>>>>>>>>> >>>>>>>>>>> All the best, >>>>>>>>>>> >>>>>>>>>>> Steve. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I hope I found a solution for opening note files with Basket: >>>>>>>>>> Suppose there is a basket in >>>>>>>>>> ~/.kde/share/apps/basket/baskets/basket106 which has a note in a file >>>>>>>>>> called note1.html and the metadata in Nepomuk is as following: >>>>>>>>>> >>>>>>>>>> $ nepomukcmd query "select ?r where { ?r nie:url >>>>>>>>>> <file:///~/.kde/share/apps/basket/baskets/basket106/note1.html> . }" >>>>>>>>>> <nepomuk:/res/00473b7a-4ac9-4223-b8d3-dee3d24631c1> >>>>>>>>>> Total results: 1 >>>>>>>>>> Execution time: 00:00:00.3 >>>>>>>>> >>>>>>>>> Where did that URL come from? Normally Nepomuk should only contain >>>>>>>>> absolute URLs. >>>>>>>>> >>>>>>>>>> $ nepomukcmd query "select ?a where { >>>>>>>>>> <nepomuk:/res/00473b7a-4ac9-4223-b8d3-dee3d24631c1> nie:mimeType ?a . >>>>>>>>>> }" >>>>>>>>>> "application/x-basket-item"^^<http://www.w3.org/2001/XMLSchema#string> >>>>>>>>>> Total results: 1 >>>>>>>>>> Execution time: 00:00:00.1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Now in Nepomuk::SearchRunner::run, we could get the service that >>>>>>>>>> should run this resource and then tell the KRun to use it, like the >>>>>>>>>> following: >>>>>>>>>> >>>>>>>>>> QString mimetype = >>>>>>>>>> res.property(Nepomuk::Vocabulary::NIE::mimeType).toString(); >>>>>>>>>> KService::Ptr preferredService = >>>>>>>>>> KMimeTypeTrader::self()->preferredService( mimetype ); >>>>>>>>>> >>>>>>>>>> KRun *newApp = new KRun(url, 0); >>>>>>>>>> newApp->setPreferredService( preferredService->desktopEntryName() ); >>>>>>>>>> >>>>>>>>>> I hope it works without changing anything else. >>>>>>>>>> Sebastian, would you please take a look? >>>>>>>>> >>>>>>>>> This is a good idea for a quick intermediate solution. :) >>>>>>>>> Very nice. All you would have to do is set the mimetype on the notes >>>>>>>>> manually. The only problem left is that strigi would add the html >>>>>>>>> mimetype, too. But we can handle that by indexing the baskets >>>>>>>>> manually. >>>>>>>>> >>>>>>>>> For the latter I need to make some API public which I need to do >>>>>>>>> anyway. >>>>>>>>> Can we meet on IRC? I am in #nepomuk-kde on freenode >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Sebastian >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Amir >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Sorry for being late. Since I could not find you on IRC (Friday 15 Oct >>>>>>>> 17:30 GMT) I am writing this. >>>>>>>> >>>>>>>> IMHO the following scenario would work fine: >>>>>>>> 0. ~/.kde/share/apps/basket should not be indexed automatically. >>>>>>>> >>>>>>>> 1. We keep the current code that adds the metadata of the basket and >>>>>>>> its notes into the Nepomuk and sets notes as parts of the basket. >>>>>>>> 2. Ask the Nepomuk::Indexer to index notes using Indexer::indexFile >>>>>>>> method >>>>>>>> 3. Develop a slot (for example resetMimetype) that clears mimetype of >>>>>>>> the notes and sets it back to application/x-basket >>>>>>>> 4. connect Nepomuk::indexingDone to the newly developed slot in basket >>>>>>>> (resetMimetype) >>>>>>>> >>>>>>>> This way, the only thing that would be changed in the Nepomuk it that >>>>>>>> the indexingDone signal is implemented and it is supposed to be >>>>>>>> emitted. >>>>>>>> >>>>>>>> >>>>>>>> Please let me know your opinion. >>>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Amir >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
