Hi Matt, I submitted a new merge request; sorry for being late.
Thanks, Amir On Mon, Jan 3, 2011 at 6:08 AM, Matt Rogers <ma...@kde.org> wrote: > Amir, > > I went to merge this and noticed the merge request was still closed. > Rather than continuing to use the same old merge request, can you > submit a new one based on current master? > > Thanks, > Matt > > On Tue, Dec 28, 2010 at 11:37 PM, Matt Rogers <ma...@kde.org> wrote: >> Thanks Amir, >> I will merge this by the end of the week. >> Matt >> >> On Sun, Dec 19, 2010 at 10:34 PM, Amir Pakdel <pak...@gmail.com> wrote: >>> >>> 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 >> >> > ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Basket-devel mailing list Basket-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/basket-devel
