Latest posts

• Translations and Better Auto-Completion

  Published on sam 27 juillet 2013 in Nepomuk, (Comments)

  This blog post presents several small steps that made the new Nepomuk query parser closer to be useful for every user. The most important one is that its localization features work, the other is that the auto-completion now is more clean and elegant.

  Before speaking of new features, a good news: my work now lives in the official Nepomuk repositories! I got a KDE Developer Account, and you can find everything in the steckdenis-gsoc2013 branches of nepomuk-core and nepomuk-widgets.

  The Query Parser in French

  Even if I don't live in France (I live in Brussels, Belgium), my native language is French. In fact, Belgium is a country where half the population speaks Dutch and the other half French. There is also a group of people speaking German. In Brussels, the capital, about 80% of the people speak French.

  That's for the geolinguistics. What interests most readers is that I translated my Nepomuk query parser in French. This was quite easy: every translatable string is wrapped into a i18nc() call, and adding a small Messages.sh file in the Git repository enabled me to extract these messages using a script of the KDE Localization project. The translations were extracted into a .pot file, that I just had to edit using Lokalize. When every string was translated, I saved the file and installed it on the right place on my system.

  The result is shown in the following screenshot, that will surely look familiar to French-speaking people:

  

  The .pot are not in the Git repository because it does not belong there. When my work will be merged into the master branch of nepomuk-core, scripty (the script that updates translations on the KDE Git and SVN repositories) will extract the translatable strings and will put them on the SVN repository used by the KDE translators. Each language will then have its own translation of the parser.

  Simplifying the Auto-Completion Box

  The auto-completion box as shown in this blog post was made of pages. The first one displayed patterns (what the user can enter and its meaning), the second one was used for strings (tag names or contacts), and the third one was a QCalendarWidget, that allowed the user to select a day.

  Even if this worked, there were several problems in this approach. The first one is that the code was not very nice, there was duplication between the pages. Another problem was that the QCalendarWidget may not be compatible with other calendar systems. Finally, as you can see at the beginning of the blog post, the widget was not very nice. Sure, the page displaying patterns had charm, but the list of strings looked too simple.

  Another problem, that cannot be shown using screenshots, is that getting a list of strings is very difficult. As this list of strings replaces the list of patterns, there must be only one pattern in the list. This means that you won't get the list of your tags if your query is even slightly ambiguous, and it is easy to be ambiguous. For instance, "sent to" shows three patterns: "sent to [contact]", "to [contact]" (ignoring the "sent") and "sent [date-time]", as the pattern matched does not know that "to" will never be a valid date-time. In this case, even if you know what you want, the query builder with not show you anything.

  The solution I adopted is to get rid of the pages. Now, the completion box only shows patterns (this was the nicest page). When values can be auto-completed, they are so directly in the pattern list. For instance, if you type "sent to Nep", the auto-completion box will show "sent to 'Nepomuk Mailing List'" and "to 'Nepomuk Mailing List'". This way, the user gets value proposals even if its query is slightly ambiguous. And this is nicer than a big list of strings without any formatting:

  

  This change also removed hundreds of source lines of code. I'm always happy to improve things while removing lines. The only "regression" is that the calendar widget is gone, and I still need to find a way to tell the user that he or she can enter human date-times ("if you want to open a calendar to find what is the first Monday of next month, just type 'first Monday of next month'").

  When KRunner Works out of the Box

  After having integrated the query builder widget into Dolphin, I wanted to see if there was something needed to parse Nepomuk queries in KRunner. Before cloning any git repository, I tested my distribution KRunner. As I install my development libnepomukcore system-wide (this allows me to check that everything is binary-compatible), entering a query in KRunner yielded:

  

  What a nice surprise! Nothing to do, KRunner is able to use my new parser without any modification. I thought that working on an already well-known library is a very pleasant experience, because you don't improve one application, but every application that uses the library. Furthermore, the fact that KRunner did not crash means that my work is fully binary compatible with the old query parser (as I reused its .h header, I was quite confident in that).

  Other bugs fixed

  The other changes don't deserve a screenshot. For instance, I fixed how date-time intervals are parsed (there was a typo that made weeks one-day long, and another one that inverted December and September) and I improved how relative weeks are handled. For instance, "second week of next month" now works as expected. This fix also simplified the code.

  The query builder widget was also slightly improved. Its sizing is now more consistent, and I removed the sizeHint() method (that I simply ignore now). All in all, the parser and the query builder now work way better. I also added Doxygen comments to CompletionProposal. I still have to do that for the query builder widget itself.

  Some days ago, I wondered if implementing a Firefox extension that recognized e-mails and contacts in webmails was a good idea. I read documentation about that and it seems possible, users using webmails will be able to enjoy the Nepomuk features. Before doing that, I will first check that nobody has done something like that. The KDE QuickGit for instance lists interesting repositories, like nepomuk-web-extractor.

  I also add that if you have queries that you think the parser should be able to parse, don't hesitate to tell me. There may be whole classes of queries that I haven't thought of.

• Integrating the Query Builder into Dolphin

  Published on mer 24 juillet 2013 in Nepomuk, (Comments)

  Something that works is good, but something that works great is better. These past days, I fixed many bugs and imperfections of the new Nepomuk Query Parser and the Query Builder widget. I will summarize theses fixes shortly, then will come the screenshots.

  Syntax-highlighting, one more time

  Before my holidays, I implemented the Query Builder widget as a syntax-highlighted QPlainTextEdit. This was easy and fun, and the result looked quite nice. You can find the whole story here.

  

  After that, I decided to rewrite the implementation from scratch to give it a different look. I wanted to have boxes around parsed terms, with a small cross to remove them. After some days, the widget looked like that:

  

  This widget was really nice, but its implementation did not seem very clean. Furthermore, the widget was made of a complex tree of line edits, buttons and widgets responsible for drawing the boxes. Handling the cursor position (and the text itself) was a bit hackish, and some things did not work well (you were unable to select all the text of the widget, for instance, and focus handling was a bit special).

  On Sunday, I thought of a new implementation that has the simplicity of the syntax-highlighted QPlainTextEdit, with the look of the complex widget tree.

  At the start of the day, I wanted to use a QTextEdit with a custom style sheet and custom HTML. My plan was to use the HTML renderer of Qt to draw the boxes around the parsed terms, and to use the Unicode "×" character to provide the cross. I wanted to implement the closing cross using a custom mousePressEvent method and something like characterAtMousePosition() == '×'.

  Finally, I discovered that the HTML engine of Qt does not support rounded corners (and does not seem to support border colors at all). So, I decided to do all the drawing myself, in a paintEvent method. I tried to subclass QLineEdit, but this class does not allow me to map a character position to a x coordinate. Finally, I used QPlainTextEdit, because QTextDocument allows me to map a character position to a x coordinate:

  1 2	QTextLine line = document()->findBlock(0).layout()->lineAt(0); int x_pos = line.cursorToX(char_index);

  Using this, I'm able to easily draw boxes around terms, and this is fast. The only problem is that there is no crosses. I first wanted to add " ×" after each box, but this would have required to change the positions of the boxes. If a box spans characters 2 to 6 without a cross, it needs to be extended to character 8 with a space and a cross at its end. Furthermore, the following boxes need to be adjusted 2 characters to the right. This would have been too complicated for a feature not really needed.

  With the third version of the query builder in place, I was able to fix many bugs. Text selection now works correctly and as expected, and the auto-completion widget was enhanced. It preselects completions based on what the user types (if I type "tagged as Im" and I have a tag named "Important", it will be pre-selected), and many little details like size hints are now saner.

  Playing with Dolphin

  Yesterday, I wrote a small patch for Dolphin to integrate the query builder in it. When Dolphin is built with Nepomuk enabled, you can enter user queries with the help of the query builder widget. The result is quite nice and I hope that this patch will be merged in the next KDE release. I don't post it yet on Reviewboard because the API of the query builder is not yet fixed.

  

  The next steps are now to integrate the query builder in more applications (maybe Plasma Active), and to fix even more bugs. I also have to document the public API of my code.

• The Journey to Auto-Completion

  Published on ven 19 juillet 2013 in Nepomuk, (Comments)

  Sometimes, features are simple to describe, and their implementation also ends up being simple and small. However, the reflection needed to come with the implementation can be quite substantial. This blog post relates my journey to the auto-completion feature of the Nepomuk query parser, a feature described as "show to the user want he/she wants" and implemented in less than 1000 lines (empty lines and license headers included), but that took a whole week to implement.

  Features

  Before explaining how the auto-completion works, let's start with the parsing itself. As described in previous blog posts, the Nepomuk query parser tries to find in the user query lists of contiguous terms that match a certain pattern. For instance, if the query is "mails sent to Jimmy", "sent to Jimmy" is matched against "sent to %1".

  The idea of the auto-completer is to use these patterns. What the user wants is to be able to type the beginning of a pattern, and to have all of it auto-completed. When what the user has entered corresponds to the beginning of a pattern, this pattern is shown as an auto-completion proposal. When the user selects a proposal, the pattern is put into the query builder and the user can continue its input.

  

  When there is only one possible pattern, that is to say when the user is unambiguous about what he or she wants, then a more intelligent auto-completion can be used. As you can see, the auto-completer knows the type of the value associated with a pattern. "tagged as %1" for instance expects that the user will enter a valid tag name. So, when there is only one possible pattern, a one-item list is not shown (it would be useless), but instead an auto-completion box adapted to the type is displayed.

  

  

  You see that tag names and date-times use a different auto-completion widget. As this is still preliminary work, the list is not sorted, there is no search interface (it would be difficult to do in a popup, by the way), and contacts are not yet handled. This is not because it is technically difficult (contacts can be enumerated just like tags), but because I don't know how Akonadi stores contacts in Nepomuk, if it does, and if it is what most of our users want (the majority of users nowadays use web-based email clients and proprietary instant messaging services).

  Auto-Completion in the Parser

  My work on auto-completion has been split between the parser and the query builder widget. The parser is responsible for finding the auto-completion proposals. It knows the list of all the possible patterns, their types, etc.

  The first step was to add a CompletionProposal class (in the Nepomuk2::Query namespace). This class simply stores a a pattern (a string list of terms that must be matched), a type (whether the user needs to enter a tag name, a date-time, or a simple string), a textual and localized description, and positional information. This positional information tells what part of the user query needs to be replaced with the auto-completion if the user selects it. For instance, an auto-completion for "sent to" in "mails sent" will preserve "mails", but will replace "sent" by "sent to |", with the bar representing the text cursor.

  As auto-completion proposals are dependent of where the text cursor is, I've added a third overload of QueryParser::parse. This method takes a user query, flags, and the position of the cursor that will be used to find auto-completion proposals. It is a bit special that the parser has to know the position of the cursor, but it greatly simplifies things and avoids generating too many auto-completion proposals, that will later be rejected because they are too far from the cursor.

  With all that done, the actual implementation is quite simple, less than 40 lines long. When the pattern matcher (the class responsible for matching "sent to Jimmy" against "sent to %1") is done with a pattern, it checks if the cursor is contained in the pattern, or very near. If it is the case, a new completion proposal is created.

  Auto-Completion in the Query Builder

  The implementation in the query builder widget is a bit bigger, because I had to add an auto-completion popup (the thing that displays the auto-completion proposals and looks like the drop-down menu of a combo box) and the widgets used to display the proposals, the tag list and the calendar (the calendar itself is a QCalendarWidget).

  After the user query has been parsed (with the position of the text cursor passed to the query parser), the query builder widget enumerates the auto-completion proposals. If the list is empty, the auto-completer is hidden. If the list contains only one entry, then a datatype-specific completer is shown. In all the other cases, each completion proposal is added to the completer, and finally displayed in a QListWidget with custom item widgets (to have the description in bold and the pattern below).

  The end result is not so bad but not yet perfect. For instance, there is no border around the drop-down completion box. I've looked at the QCompleter and QComboBox code but I have not found how they manage to have rounded styled corners and a small 3D effect.

  When the user selects a value (a tag name, or a date-time), the value is put into the query builder widget:

  

  Future plans

  Having the auto-completion in place is a nice thing because my GSoC proposal is now "bullet-point complete". That means that I proposed a query parser able to parse queries in near-natural language, and a query builder widget with syntax-highlighting and auto-completion. These three features are now present.

  But even if they are present, I no way near to the end of my GSoC. Many things need to be polished. For instance, I'm not quite satisfied of my "grouped line edit". Some things don't work exactly as I want, and the architecture is a bit special.

  There are also small bugs in the parser itself that need to be resolved, and the auto-completer is not very nice. The mockups of Ivan also contain a nice feature I would never have thought of: the translation of the parsed query back to natural language. That means than in his mockup, when he enters "music +instrumental", the auto-completer displays "looking for music tagged as instrumental". I think it is a good idea to show to the user what the query really means.

  All in all, there is still work to do and I will fix as many bugs as I can in the coming weeks. My goal is to have a very nice query builder widget, that works well and that has a code of great quality.

• A Nicer Query Builder Widget

  Published on mar 16 juillet 2013 in Nepomuk, (Comments)

  After 10 days of vacations, I'm now back at work for the rest of the GSoC period. Before my departure, I presented a syntax-highlighted query builder widget. It was based on a QTextEdit made to look like a QLineEdit, and a QSyntaxHighlighter subclass was responsible for the highlighting.

  The result was quite nice, but not as nice as what Ivan Čukić imagined for this control. Since the first instant I saw his mockup, I wanted to have a widget like that in Nepomuk. The problem is that such a widget is very difficult to implement (and even more to implement correctly), and that I haven't found any existing code on Google, and the only application using this widget I know of is Yahoo! Mail. I therefore decided to implement this widget myself.

  General Idea

  The code of the widget lives in my branch of the nepomuk-widgets repository. Even though I tried to keep the widget general (the GroupedLineEdit class does not reference any Nepomuk class), I don't think it can already be useful to other projects. Don't hesitate to prove me wrong, though. If this widget one time becomes general enough and more sane than it is currently, I would like to have it merged into Qt (the widget doesn't use any KDE class).

  

  

  The idea of the widget is to "group" terms into blocks. A block is a rounded rectangle, each of a different color, and having a small cross. When the user clicks the cross, the group is deleted. The blocks must be completely cosmetic for the user. That means that the full query builder still needs to behave like a QLineEdit: the user must be able to move the cursor using the arrow keys of his or her keyboard, and the cursor must not be stuck at one end of a block. It must be able to flow from a block to the next or the previous. The user must also be able to add text anywhere, even between blocks.

  Blocks are added to the widget by the application, one at a time. Blocks cannot be removed, but the widget can be cleared (every block is removed, the text being preserved). When blocks need to change, the application thus clears all the blocks, then re-add the ones it needs. This is not the most efficient operation, but doing otherwise would have greatly complicated the API and the code itself.

  Flowing From a Line Edit to Another One

  "Flowing" is an operation needed when there is two line edits next to each other. When the user presses the arrow keys, the cursor moves in one of the line edits. What I want is to detect when the user tried to move left/right when the cursor was already at the left/right of one line edit. When that occurs, the cursor is placed at the right/left of the previous/next line edit. [ ][| ], with the vertical bar representing the cursor, becomes [ |][ ] when the cursor presses the left key.

  Unfortunately, QLineEdit does not allow that. When the cursor moves, the cursorPositionChanged signal is emitted. This signal contains information about the old and the new position of the cursor. The problem is that this signal is only fired when the cursor actually moved. If the user presses Left when the cursor is already on the left side of the widget, the signal is not emitted.

  I looked at the code of QLineEdit and QLineControl, and there was nothing hidden there to help me. The solution I used is to subclass QLineEdit and to reimplement its keyPressEvent method. I still need to find how to make all that work with right-to-left languages:

  1 2 3 4 5 6 7 8 9 10

  void GroupedLineEditEdit::keyPressEvent(QKeyEvent *e) { if (e->key() == Qt::Key_Left && cursorPosition() == 0) { emit cursorBeforeStart(); } else if (e->key() == Qt::Key_Right && cursorPosition() == text().length()) { emit cursorAfterEnd(); } QLineEdit::keyPressEvent(e); }

  What Next ?

  I invite you to test my code. This can be done by cloning the gsoc2013 branch of http://public.steckdenis.be/git/nepomuk-core and http://public.steckdenis.be/git/nepomuk-widgets. Then, build and install nepomuk-core, and build nepomuk-widgets. When everything is built, launch your_build_dir/test/querybuilderapp. A small window like the one shown at the beginning of this post pops up. Enter a query, and see it being highlighted in real-time.

  If you have a slow computer, don't hesitate to test my code on it. Currently, the highlighting is done every time you type a character. If your CPU usage becomes too high when you test the widget, one solution would be to highlight the query not at each character typed, but every half second or so.

  My next step now is to investigate the auto-completion stuff. Ivan also proposed a nice interface, and I have ideas on how to implement that. I hope to have something to show by the end of this week.

• Syntax-Highlighting Experiments

  Published on lun 01 juillet 2013 in Nepomuk, (Comments)

  Sometimes, I'm very happy to work with Qt, because it provides everything I need, and in a very clever way. Syntax-highlighting is one of the many areas where Qt shines.

  High-level syntax-highlighting of programming languages and configuration files is easily done using KTextEditor (the component used by Kate, KWrite, Kile, KDevelop, I think). One has simply to write an XML file describing the language to highlight, and the editor does the rest. Code-folding is also possible, as is every other feature everyone loves in Kate and KDevelop.

  For my Google Summer of Code project, such a full-fledged editor is a bit overkill. What I need is a mean to syntax-highlight a one-line text edit. The highlighting itself is simple, because the "grammar" (if it really is one) of the parser is simple.

  A One-Line Text Edit

  Yesterday, I started by implementing a small editor based on QPlainTextEdit, mimicking QLineEdit. I couldn't directly use this class because it doesn't allow syntax-highlighting, I need a QTextEdit subclass and a QTextDocument. I therefore tried to make QPlainTextEdit look like a simple line edit. This can be done by configuring it properly (setting the size policy, disabling tabs, disabling the scroll bars and the word-wrap, etc) and by reimplementing its sizeHint() method. The reimplemented method behaves like the one of QLineEdit (original code from the Qt project FAQ):

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

  QSize QueryBuilder::sizeHint() const { QFontMetrics fm(font()); QStyleOptionFrameV3 opt; QString text = document()->toPlainText(); int h = qMax(fm.height(), 14) + 4; int w = fm.width(text) + 4; opt.initFrom(this); return style()->sizeFromContents( QStyle::CT_LineEdit, &opt, QSize(w, h).expandedTo(QApplication::globalStrut()), this ); }

  The method calculates the area of the displayed text (using QFontMetrics), and then asks the style to compute the size of the whole widget. By telling the style that the widget is a CT_LineEdit, the size returned is the exact same size a line edit would have. The illusion is perfect:

  

  Choosing Colors

  After having implemented the text editor, I started experimenting with the syntax-highlighting itself. My idea was to have every ComparisonTerm displayed in a different color, with the literal terms displayed in bold. During the development, I also thought that it would be nice to have "type hints" (mails, photos, documents, files, contacts, etc) displayed in italics.

  My first idea was to follow the interface given by Ivan Čukić here. The problem was that I don't even know how his "single-line edit with grouped terms that can be removed by clicking on a cross" is officially called. So, I've found nothing on Google that could help me to implement that. I tried different solutions, but there were always problems (for instance, a QLineEdit draws its white back-ground and its text in one step, so I cannot draw boxes between the two). In order to still be able to experiment things, I decided to use a simpler approach (syntax-highlighting) for now.

  In the above image, you can see that every comparison term is highlighted in a different color. The colors are coming from the Oxygen palette, and are roughly all of the same luminosity. It is very difficult to find colors that look well with each other, so if you have ideas, don't hesitate to tell me. I have selected 8 colors, and the highlighter cycles between them.

  I also tried to use HSV colors (Hue, Saturation, Value). Saturation and Value were forced to values often found in Oxygen colors, and the hue was incremented by 71 degrees every-time the color had to change. The result was ok, but not so nice. Sure, there was up to 360 different colors, but they were mostly bad-looking and difficult to read. I abandoned the idea and decided to use Oxygen colors, that were carefully crafted by the great designers of KDE.

  I developed this experiment directly in the Nepomuk Widgets repository. As I have no KDE developer account yet, the repository can be found at http://public.steckdenis.be/git/nepomuk-widgets . My code is in the gsoc2013 branch. Feel free to experiment and to modify the colors (a table in ui/querysyntaxhighlighter.cpp).

  UPDATE:

  Most users will never or very rarely use comparison terms. All they want is a tool that returns a list of documents matching terms. The syntax-highlighter I presented in this blog post chooses a different color for each comparison or literal terms. Queries like "cat dog rabbit" therefore are highlighted using 3 different colors, every term being in bold. This is not really nice.

  So, I changed the highlighting a bit. Now, literal terms are not highlighted at all, only comparison terms and resource type terms (type hints) are. For comparisons, the whole comparison is colored, and its part that is not a literal term is also rendered in italics. So, "foo bar sent by Jimmy" becomes "foo bar sent by Jimmy":

  

  Another modification is that nested queries are detected and underlined, so the user can see where it ends, and potentially why its query does not return the expected results:

  

• Merging the parser

  Published on ven 28 juin 2013 in Nepomuk, (Comments)

  As my query parser begins to be useful and to work well, I want to start working on the syntax-highlighted input field. As I do not want to multiply the experimental repositories (people need to find them, to build them, and when the work is upstreamed, I have to put a big notice saying that the repository is outdated), I plan to develop the input field in a separate branch of nepomuk-widgets.

  The syntax-highlighted input field needs to use the query parser. If the query parser remains in a separate Github repository, I have to add it as an external dependency in nepomuk-widgets. Furthermore, I think for some days now that it would be interesting to see how the new parser integrates with Nepomuk as a whole.

  Merging git subtrees

  • My branch of nepomuk-core: gsoc2013 of http://public.steckdenis.be/git/nepomuk-core/. It will move to the official Nepomuk Core repository once I get a KDE developer account and the Nepomuk maintainers allow me to push the branch.

  I love history. I think that big squashed merges are difficult to get reviewed because reviewers need to read and understand thousands of lines of code at once. When the development history is kept, it can be viewed progressively. The only problem is that development is never a straight line going towards the finished product. There are experiments, sometimes something gets reverted or canceled, or things simply change.

  In the case of my parser, the grammar of the pattern matcher has changed after 2 days of development, and the pattern matcher became a class on its own a bit later. There are also parsing passes that got removed or merged into other ones (hourminute, that was responsible of recognizing hours and minutes, is now merged into datevalues, that assigns values to hours, minutes, seconds, and also days, months, weeks, etc).

  I decided to add my parser into the Nepomuk Core source-tree, with its full history. I found some interesting instructions on Stack Overflow, and everything worked perfectly. Now, my branch of the nepomuk-core repository contains a new directory: libnepomukcore/queryparser/. All my files are there and build perfectly. I also removed the old query parser (it was just one file).

  The new query parser is source- and binary-compatible with the old one. In fact, its .h header is the same as the one of the old parser. I simply copied it, and changed some parts of the documentation (the syntax is not the same, limitations are lifted, and other limitations are temporarily added).

  Building libnepomukcore was simple and there was no problem. I fixed two compiler warnings exposed by the use of GCC (I usually compile with Clang) and optimization flags that uncover reads of uninitialized variables. When everything was built, I was able to launch nepomukquerytester, a tool that allows me to enter queries and to get the resulting SPARQL query that will be sent to the storage backend:

  

  Some days ago, Vishesh Handa developed a cool new utility called nepomuksearch. It is a command-line utility (with nice colors) that takes a query on its command line and outputs the corresponding documents. Without any modification, it was able to use my new parser to show my files. Keywords, properties, dates, everything work. I was able to list the files I modified yesterday simply by searching for "modified yesterday". Nice.

  Now that the parser is merged into Nepomuk, I can build a libnepomukcore library that contains everything the syntax-highlighted input field needs.

  Positional information

  Another new feature of the past days is that the parser stores positional information into the terms it produces. A term is the data-structure used to represent a parsed query. There are literal terms (integers, strings, date-times), comparison terms, resource type terms ("mails" gives the hint that e-mails must be returned by the query), and logical terms (and, or, not), among others.

  I have submitted a review request to the Nepomuk developer, asking them if I can add two fields to the base Term class. One of those fields is a position, the other is a length. They allow the parser to remember from which portion of the user query string it parsed terms.

  Every term has positional information, not only literal ones. For instance, a comparison term covers the part of the user query that describes the comparison. For "mails sent by John", the comparison terms covers "sent by John", the resource type term is linked to "mails", and the literal term simply is "John".

  With this tree of terms, each having positional information, it is possible to do a pretty neat syntax highlighting: use a different nice color for each term, and render literal terms in bold face. This way, the actual content (the literal terms) is clearly seen by the user, and he or she also sees if properties are correctly recognized. An example of highlighted query is "mails sent by John" (I used italics font instead of colors).

  Syntax-highlighting is not the only way of representing this kind of information. For instance, Ivan Čukić proposed a very great user interface that you can see here. I really find it beautiful and congratulate Ivan for it! I will see how it could be implemented with my parser (that recognizes complex patterns, even mixed patterns where date-times are spread between property comparisons).

  Timing

  We are now at the end of the second week of the Google Summer of Code. My project is composed of two big parts:

  • The query parser (in the sense of "something that takes a query string and produces a Nepomuk2::Query::Query object")
  • A "query builder widget", a widget used by Dolphin when you click on "Search" and that allows the user to build queries without having to understand how the parser works. The query parser recognizes a language close to natural language, but this widget can also help the user by exposing auto-completion suggestions (tag names, contacts, file-names, date-time popups, etc), and decorating the input with some nice colors

  The query parser is in good shape and is able to parse queries. When porting the unit tests from the old parser to the new one, I have found that some features still are lacking (like the recognition of file-name wild-cards), but it is already quite usable, and produces positional information.

  The query builder widget will be very interesting to develop. The challenges will be graphical (the interface of Ivan is very nice but seems difficult to implement, and even more to implement right) and algorithmic, as the parser will need to be adapted (for instance, if a pattern like "sent by %1" only partially matches, it can be used to add a new auto-completion proposal).

  I'm on holidays from July 3 to July 13, so there will be no new blog post during this period. Before that, I will try to advance as much as possible in the implementation of a nice query builder widget. I'm very excited, and nice-looking things always pleased me. After my holidays, I will have nearly two months and a half to finish the query builder widget, fix bugs, and integrate Nepomuk at interesting places (KRunner, Plasma Active, etc). I'm open to any suggestion.

« Previous Page 6 / 11 Next »