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
