Hi Sebastian, Thanks for your reply.
On Mon, Nov 1, 2010 at 12:43 PM, Sebastian Trüg <tr...@kde.org> 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"? > > "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] 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 <pak...@gmail.com> wrote: >>> Hi Sebastian, >>> >>> On Fri, Oct 22, 2010 at 5:18 PM, Sebastian Trüg <tr...@kde.org> 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 <tr...@kde.org> 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 <tr...@kde.org> 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 <steve...@gmail.com> >>>>>>>>> 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 >>>>>>> >>>>>> >>>>> >>>> >>> >> > ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Basket-devel mailing list Basket-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/basket-devel
