[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Parsing user queries in Baloo
From:       Vishesh Handa <me () vhanda ! in>
Date:       2014-03-08 15:03:51
Message-ID: 77492412.qgfQEHvjQi () vlap
[Download RAW message or body]

On Friday, March 07, 2014 07:46:50 PM Denis Steckelmacher wrote:
> On 03/07/2014 05:38 PM, Vishesh Handa wrote:
> > On Saturday, March 01, 2014 10:44:35 AM Denis Steckelmacher wrote:
> >> Hi,
> >> 
> >> After having read most of the source code of Baloo and its main clients
> >> (the search runner and Dolphin), I'm beginning to see how the whole
> >> thing fits.
> >> 
> >> I'm looking for a way to integrate the user query parser that I
> >> developed during the summer, and I currently see two places where it can
> >> be integrated:
> >> 
> >> * In Baloo::Query::setSearchString : if a flag is activated somewhere
> >> and if the backend supports Baloo::Term objects, then the search string
> >> can be parsed. The parsing will then set the query type (files, e-mails,
> >> musics, etc) and its top-level Term.
> >> * In a new publicly-available parser that returns a Term and a type.
> >> This will not change the behavior of Query::setSearchString, but every
> >> client application that wants to use the parser will need to be modified
> >> to manually call Query::setTerm on the queries it constructs.
> > 
> > Or it could just return the Query object?
> > 
> > Denis, could you see what all changes you'll need in the existing Term and
> > Query classes. You'd needed some setUserData function when you were adding
> > this to Nepomuk. Lets try to get these changes in as soon as possible.
> > That
> > way your stuff can be compiled on top of 4.13
> 
> The most important thing is Term::(set)position() and
> Term::(set)length(), so that the query builder can use this information
> to highlight the queries entered by the user. I don't think I need more
> information (the Nepomuk version of the query parser doesn't use more
> than that), but setUserData and getUserData are more general solutions,
> that were preferred to specific setters/getters back then.
> 

Cool. Feel free to add the same setUserData functions in Baloo::Term.

> The rest seems to be there: terms have comparators, property and values
> are general enough (QVariant-based properties allow me to put QDateTimes
> in them if supported by the backend), negations and sub-terms are
> handled, so are boolean operations. I think nothing is missing and
> everything that I used survived the port to Baloo.
> 
> I have some free time this week-end and I will try to advance on the
> port tomorrow. I should be able to give you more details after that.
> 
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
> >> <<

-- 
Vishesh Handa

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]