On 03/10/2014 07:54 PM, Vishesh Handa wrote:
> I'd love for you to get more involved in Baloo, as you have tons of
experience
> from Nepomuk. And you're a pretty good coder!
Thanks! I would be glad to work on Baloo, the codebase is very clear and
easy to understand. The projects involving the file indexers and writing
metadata back into files seem very interesting (I also followed the
discussion about xattrs).
I think that I will have some free time the coming weeks. By the way,
would it be possible for me to submit a GSoC proposal for Baloo? Are
proposals like "doing these 10 small things" accepted by KDE? I'm also
quite interested in KDevelop, but Baloo is something fresh and new and I
very much like fresh and new things :)
The first commit in my branch adds the methods Term::setPosition,
Term::setLength, Term::position and Term::length. I finally chose to use
these methods instead of a more general setUserData and getUserData,
because I think that exposing a clear API is better than saying "to get
the position of a term, pass _k_term_position to getUserData".
Hmm. Alright. Ignore my previous comment then.
Though who would be the potential consumers of this API? Just the query
parser?
For the moment, the only client of this API is the query builder widget.
Maybe someone will one day want to use this API (to implement another
query builder widget or in a search store), but I agree with you that
this API is not very useful.
Well, this is primarily cause the backends do not support regular-expressions
that easily. We can do a regexp match in the file search store, but it will
involve match every single file url.
Is SQLite able to use regular expressions? I have not yet read all the
fileindexer code, but there is a sqlite database somewhere that could be
used for that, if feasible.
* Date-times are handled by Query, using setDateFilter. The parser
properly lowers date-time comparisons to date filters (see
QueryParser::tuneTerm for all the lowering that takes place), but there
is nothing I can do with times or more advanced comparisons (before a
date-time, between two date-times that are not aligned on a
year/month/day boundary, etc).
The API does support it right now, correct? I'm thinking of something along
the lines of Term("modified", date, LessThan). The only problem is the backend
not supporting it.
Do you want to add support for that? It should be fairly trivial. Have a look
at how the email search store does it.
It's a good idea, I will take a look at that.
What about the widget side of this?
Also, this brings us to the question of how/when do we want to ship this. I'm
not very comfortable with shipping it with this release cause it would mean
more APIs which we have to stick with.
On option is that we could ship it as a separate library, and not as part of
baloocore. This way we can potentially not maintain source/library
compatibility on that library. Otherwise this can be shipped separately on top
of Baloo.
What are your thoughts on this? Where would you like to see this go?
The widget still needs to be ported. It should be very simple, though,
as it does not depend on anything that was in nepomuk-widgets and only
uses the QueryParser and Term classes.
If I'm not mistaken, the next version of KDE Platform that will come out
is 4.13. I don't expect the query parser to be shipped in this release
(this is still very experimental code added after the first beta), so I
have nothing against releasing the query parser with KDE Platform 4.14
(or 5). As the query parser is tightly coupled with the search stores
(it has to use the same properties as them), and to increase its usage,
I'd prefer to keep it in Baloo Core.
Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
