Hi everybody, Since I have been using my version of Basket with Nepomuk Integration for some times now without any problem, I have submitted a merge request (merge request #9).
Dear Sebastian, Do you have any plan to include my patch into the KRunner? Thanks, Amir On Tue, Nov 16, 2010 at 10:21 AM, Amir Pakdel <pak...@gmail.com> wrote: > Hi everybody, > > Would you please kindly give it a try before I submit the merge request? > I would be grateful if anyone could review my code too. > > Thanks, > Amir > > > ---------- Forwarded message ---------- > From: Amir Pakdel <pak...@gmail.com> > Date: Thu, Nov 11, 2010 at 6:38 PM > Subject: Re: [Basket-devel] Loading Baskets from the command line > To: Sebastian Trüg <tr...@kde.org> > Cc: basket-devel <basket-devel@lists.sourceforge.net>, ma...@kde.org, > nepo...@kde.org > > > Hi Sebastian, > > I hope that I have done it right this time :D > Would you please take a look: > http://gitorious.org/~pakdel/basket/pakdels-basket/blobs/master/src/nepomukintegration.cpp > > Moreover, I have changed NepomukSearchRunner a little bit, so I could > search for contents of notes using KRunner. I have attached the patch > for that too. > > Thanks again for your help > > > > > Dear developers, > It would be great if anybody could test it. > > > Thanks everybody, > Amir > > On Mon, Nov 1, 2010 at 2:16 PM, Sebastian Trüg <tr...@kde.org> wrote: >> 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 <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"? >> >> 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 <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 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Basket-devel mailing list Basket-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/basket-devel
