On 03/10/2014 08:55 PM, Vishesh Handa wrote:
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?
Not really. Polishing Baloo and general work may easily take the whole
summer, but I currently have no idea of a big project that could bring
something entirely new to Baloo.
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"?
Ok, I agree that setUserData and getUserData is more extensible and
exposes less internal data. I will adapt the parser in the coming days.
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.
The query parser has to know that a file size corresponds to the "size"
property and that the recipient of an e-mail corresponds to the "to"
property. The same applies to the date of creation/modification of files
(when they will be implemented). Other clients of Baloo either use the
parser or build their queries themselves and have to ensure that they
use the correct property names.
Are these property names considered "internal" (and therefore subject to
change) or are they stable? If they are stable, then the query parser
can be put in a separate library if it is the best solution.
Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
