On Monday, March 10, 2014 08:29:35 PM Denis Steckelmacher wrote: > 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 :) >
It's generally preferable to have a proper large project. Though it depends on how big those "small things" are. Did you have anything in mind? > >> 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. > Maybe then a more generic API, however ugly, would be preferable. How about using just "position" instead of "_k_term_position"? > > 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. > It seems like it - http://stackoverflow.com/questions/5071601/how-do-i-use-regex-in-a-sqlite-query But it's not going to be very efficient. I'm not sure if this is something we want to expose. > >> * 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. > I'm not sure I follow - It is strongly coupled with the search stores, but then so is all searching. -- Vishesh Handa >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
