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
