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
