Articles in the Nepomuk category

• The coding period starts tomorrow

  Published on lun 19 mai 2014 in Nepomuk, (Comments)

  Hi!

  The Google Summer of Code coding period starts tomorrow. I have done everything possible in order to have plenty of time to dedicate to my project, adding support for QML and Javascript in KDevelop, and many interesting things are already happening.

  Import statements and code-completion for QML Components

  When using QML, it may be quite frustrating to have to constantly read the documentation in order to discover what components do exist and what are their properties, signals and slots. The QML/JS plugin aims to solve this problem by implementing two features:

  • Support for special files that describe the QML components available on a system. These files, named plugin.qmltypes, are valid QML files that describe the components of a module and their signals, slots, methods and properties. These files even list all the enums exposed by Qt to the QML world, with their enumeration values. It is, in fact, a complete dump of what a C++ compiler could discover by reading all the Qt header files.
  • Support for import statements. When the user imports a module, the plugin loads the corresponding plugin.qmltypes file and adds its declarations to the global scope of the file currently being edited.

  The first point has already been implemented and works quite well. It was fairly easy, as there is nothing to guess. The plugin.qmltypes file provides everything needed, as shown on this picture:

  

  You see that the parameters and their types are identified. The return type of this signal (strange... a signal with a return type) is also recognized.

  Support for import statements is not there yet, but is the subject of my first week of work. I'll keep you informed!

  I'm going to Randa

  A couple of weeks ago, I was asked if I could attend the Randa meeting. As Switzerland is not too far from Belgium (less than a day by train), and because I always wanted to meet KDE developers "in real life", I accepted. I will have the occasion to work on KDevelop, the KDE SDK, and I also plan to discuss and work on Baloo with Vishesh Handa (my GSoC project of last year was a user query parser for Baloo).

  The place seems great and many developers will be there. I am really looking forward this week at Randa, and I want to thank Mario Fux and the others who make this meeting possible!

• GSoC 2014: Improving the QML/Javascript Language Support of KDevelop

  Published on mar 22 avril 2014 in Nepomuk, (Comments)

  Hi!

  I'm pleased to announce that I have been accepted as a student for this year's GSoC. After having worked on Nepomuk (now Baloo), I will have the chance to work on KDevelop, the wonderful IDE based on KDE technologies.

  How KDevelop Supports Languages

  The code editor component of KDevelop is based on Kate, which provides the basic syntax highlighting and editing capabilities (history, cut and paste, formatting, code folding, etc). KDevelop adds some nice features on top of that, for instance code completion and refactoring.

  These features require that KDevelop understands the language used by the user. KDevelop has to know how a variable is declared, when it is used, what is a class in the language used, how functions look like, which symbols are visible in a particular context, etc. This is done using language support plugins that build something called a definition-use chain.

  The job of these plugins is to parse a document and to build the definition-use chain for them. For instance, when a variable assignation is encountered (a = 2), the plugin informs KDevelop that the variable "a" has been used. When a variable declaration is encountered, the plugin tells KDevelop where this declaration occurs. This way, KDevelop can highlight the variables in different colors, and if the cursor is on a variable, KDevelop can show on which line the variable has been declared.

  The plugin is also responsible for finding the types of the variables. For instance, "a" has been declared on a particular line and is of type "int". This information is very useful to the user.

  Javascript and KDevelop

  My project for the Google Summer of Code consists of improving the Javascript support of KDevelop. KDevelop already has a minimal JS support (variable and function declarations are supported), and my job is to add support for arrays, prototypes and "objects", anonymous functions, and the QML language. As the future of KDE will be built on top of Qt5 and QML, having a good Javascript support in KDevelop is becoming important.

  

  The most challenging part of Javascript is that it is a dynamic language. The source code does not contain any type information, and infering the types of the variables is a great service to the users. It is also necessary in order to support auto-completion of array keys (KDevelop has to know that window.location is of type string in order to offer the methods of the String class as possible completions).

  Type inference is an intersting topic and I worked on it for about two weeks (the first one was mainly thinking and discovering how KDevelop language plugins work, the second one was actual coding, and the third one was dedicated to submitting review requests for all that). The above screenshot shows that KDevelop is able to infer the return type of the function (the equality operator always returns a type), the type of the parameters (when the function is called, I give it integers, so these parameters are likely to be integers), and the type of the variable.

  Other type inference mechanisms are also implemented. If I declare a variable and give it a value, the variable will take the type of the value. var a = "foo"; declares a variable of type string, and writing a = 3; after this line will change the type of "a" to "unsure (string, int)", because KDevelop cannot say if the variable is a string or an int (I advise the user to avoid writing code like that :-) ).

  Plan for the Summer

  This project is very interesting and there are still many things to do. Functions and variables now work reasonably well, but there are many built-in features of the Javascript language that need to be supported. Arrays and hash tables, for instance, need to be supported for the code-completion to work correctly, so are built-in types (String, Integer, etc). Functions that serve as constructors also need to be detected, so that lines like var o = new Object(); declare o as being an object, with methods and members.

  Furthermore, special QML constructs need to be supported. QML has import statements, a special way of declaring objects (by attributing them an "id"), properties having their type declared, etc. This is all very interesting and I hope to be able to support all that by the end of the summer!

• Porting the Nepomuk Query Parser to Baloo

  Published on lun 10 mars 2014 in Nepomuk, (Comments)

  As explained in my last blog post, Nepomuk has been replaced by Baloo, a new and simpler implementation of a desktop search engine built on the experience of Nepomuk. One consequence of this new project was that my query parser, that I developed during the GSoC 2013, was left in the Nepomuk world.

  Several days ago, after university assignments and exams, I was finally able to find some time to dedicate to KDE. I used it to port the Nepomuk query parser to Baloo.

  Baloo: Simple yet Powerful

  The first thing that I needed to do before porting the query parser was to somewhat understand at least parts of the Baloo code base. I needed to find what was available, what was still compatible with Nepomuk-based code (Baloo keeps all the best ideas of Nepomuk), and where to put the parser.

  I was quickly able to find my path in Baloo, as the code is much smaller than Nepomuk. The infrastructure is also simpler (in fact, the Nepomuk one was very complex, I remember having to wander in different levels of abstraction of the client side and on the server and finally in Soprano in order to find where a value was changed in a way that I did not like). In fact, everything in Baloo is clean and simple.

  For instance, in Nepomuk, we had a Term class that represented "something" (a date-time, a comparison, a keyword, and also AND, OR and NOT operations). This class had many subclasses, one for each type of term. There was a LiteralTerm for simple values (a word, a number), a ComparisonTerm for comparisons (comparing a property with a literal term), and terms for logical operations. OrTerm and AndTerm both represented a logical operation, but were different subclasses with no common ancestor (except Term). My parser had to duplicate code in order to handle AND and OR comparisons, even though OrTerm and AndTerm behaved exactly the same way.

  In Baloo, there is only one Term class that does everything. It may seem to be poor engineering, but it is actually very efficient and clean. A term is made of a property, a comparison operator, a value, a logical operator and subterms. AND and OR terms are simply terms whose logical operator is set to And or Or. No code duplication, I can simply use the subterms without having to worry about the logical operator. LiteralTerm is also gone and the API is far cleaner: gone are the Soprano::LiteralValues and complex property URIs. Properties are now simple strings, and values are QVariants.

  Porting by Removing Code

  The porting process began by copying the entire query parser into a new directory in Baloo Core. At first, I did not want to drop the entire history of the parser (Git has nice tools to merge code from somewhere into a new repository, without loosing any commit), but I finally thought that the history would only be noise, and that the parser would in fact never compile before the port is complete. I also sed'ed the files in order to change every occurence of Nepomuk to Baloo (in the comments and the license headers).

  I started with the glue between the parser and Baloo. In Nepomuk, I needed a small utils.cpp file that performed repetitive tasks of wrapping and unwrapping terms from the Nepomuk world to the one of the parser. It contained several one-line and two-lines functions. I was very happy to remove most of these functions when porting to Baloo, as Baloo is clean and does not need repetitive boilerplate in order to use it.

  When the utility functions were ported, I attacked the parsing passes. Each parsing pass is quite small and independent from the others. I was very surprised to see that the porting mostly consisted of removing code. I do not need anymore to pass LiteralTerms around and to build comparisons one small step at a time (first the operator, then the property, then only the value). A pass that consisted of 100 lines in Nepomuk is now reduced to approximately 60 lines.

  Finally, I had to port the parser itself. I expected that to be a big task, as the parser consists of the pattern matcher (doing the proper recognition of "sent to X") and everything needed in order to parse date-times. Finally, it took only one day, and I was able to remove many lines of code. No big feature was lost and no big refactoring was done, as Baloo is still quite close to Nepomuk, but I was able to remove many duplicated lines and boilerplate. For instance, there were 40 lines just to recurse in the subterms of terms (using a different method for inversions, AND and OR). Now, a small 6-lines loop can simply iterate on Term::subterms and handles all cases (inversions, AND, OR or anything that could be invented in the future). The query parser weighted 2.132 SLOC in Nepomuk and is now consists of 1.892 SLOC.

  Trying the Query Parser

  The query parsed, ported to Baloo, lives in kde:baloo, branch queryparser. You can use it in your applications by including baloo/queryparser.h. The API is very simple and the parser does all the work. You can have a look at the unit tests in src/core/autotests/queryparsertest.cpp. Here is one unit tests, to show how simple to use the parser and Baloo are:

  1 2 3 4 5 6 7 8 9 10

  void QueryParserTest::testReduction() { QCOMPARE( QueryParser::parseQuery("size > 2K and size < 3K"), Query( Term("size", 2048, Term::Greater) && Term("size", 3072, Term::Less) ) ); }

  The parser will not be released in KDE SC 4.13, but may be finished in time for KDE SC 4.14. I also still have to port the query builder widget, but it should not be too difficult as the widget is simple and depends on nothing except the query parser and Term.

  The GSoC 2014

  Before ending this blog post, I would like to say that I will apply for this year's Google Summer of Code. Working with KDE developers is a formidable experience and I would be very happy to be able to participate again this year. I have several ideas of projects, but if you think of something involving a parser, artificial intelligence, or low-level stuff (optimizing something or stuff that generally gives headaches), I would be glad to hear of it. Here are the ideas (found on the KDE Ideas page or "invented") that currently interest me the most:

  • Working on Baloo, because I already know the library (and I like it). There are many small things to do everywhere (new file indexers, adding features, implementing more fine-grained date filters, etc), but I don't know if there is a big three-month project that could be done. I'm thinking about it :) . If you dream of something exciting that could be done using desktop search, I'm all ears.
  • Giving love to the KDevelop QML/JS language plugin. The plugin is already in a fairly good shape, but its maintainer has ideas of many improvements that could span an entire summer. What could be very interesting is parsing the QML files shipped with Qt (and Plasma and any other QML "library") in order to offer auto-completion of the items they expose. An item gallery may also be quite useful.
  • Add the ability to preview QML files in KDevelop. There is already one such thing in QtCreator but it seems that there are not many people liking it. I need to investigate and to see if a user-friendly previewer is possible. Plasmate for instance has a Plasmoid viewer that allows for easy testing of plasmoids.

• GroupedLineEdit Reused in Subsurface

  Published on dim 16 février 2014 in Nepomuk, (Comments)

  Hi,

  It has been a long time since I last blogged about the Nepomuk user-query parser that I developed during the summer. The reason is that the university required all my time. Here is a quick blog post that summarizes what happened these last months.

  Merging the Query Parser

  For those who missed the news, Nepomuk has been "abandoned" and renamed to Baloo. The reason is that the Nepomuk developers thought that using RDF (a complete and complex system of ontologies, that require specialized databases like Virtuoso) wasn't the right thing to do in order to provide what the user want, that is to say a powerful yet lightweight search engine. RDF allows many things, but most of the users just want to look for documents matching a specific string.

  I cannot better explain the reasons, but you can read this mailing-list thread if you want more accurate details.

  What is important is that Nepomuk has been rewritten, and that breaks my user-query parser. Fortunately, the parser is pretty much self-contained, and the algorithms used don't need to change, but the way the parser provides its results to Nepomuk has changed. In Baloo, queries seem to be simpler (for what I've seen) and are not built out of trees anymore.

  In Nepomuk, a query was a big AND, containing ORs, other ANDs and actuel comparisons. Getting every document containing "test" and tagged as "important" was done using a query like AND(tagged_as(important), containing(test)) (this syntax is not used anywhere in Nepomuk but represents in-memory Nepomuk2::Term subclasses). In Baloo, for what I've seen in the source code, a query is more "fixed". Every query consists of search terms ("test" in my example) and filters (date-time filters, maybe also tags, etc). There does not seem to be any recursive data structure. Because of that, the user-query parser cannot simply convert its abstract syntax tree to a tree of terms (a very simple operation), but needs to carefully analyze the user-query in order to produce the Baloo query (or queries) that will provide the expected results.

  I'm still thinking about all that and I will contact the Nepomuk developers for advice, because porting the user-query parser to Baloo seems not to be that complex, and seems very interesting.

  GroupedLineEdit gets used by Subsurface

  Free Software and its communities are full of great surprises. One of them was when Aaron Seigo quoted me on Google+, or when the Nepomuk file indexer for MS Office 2003 files, that I developed in October, was mentioned in the KDE Commit Digest.

  Several weeks ago, just before the FOSDEM, the Subsurface team announced that the project was ported to Qt. Subsurface is a divelog program started by Linus Torvalds and now developed by a fair number of contributors, some of them being well-known kernel hackers. When Subsurface 4 was announced, I read the news (even though I don't dive, I wanted to see how a GTK+ program could be ported to Qt and what that brings as new/improved features), and I discovered a very intriguing screenshot in the user manual :

  

  Have you noticed that there is a "Tags" field? And that it contains tags highlighted in colors? When I noticed that, I thought that Linus (or someone else) had developed exactly the widget that I needed during the summer, the widget that is used to highlight query terms in user-queries, as shown in this image :

  

  I downloaded the source code of Subsurface and started to look after this widget that does exactly what I want. Finally, I found it, and I was very surprised to see that it was actually my GroupedLineEdit widget that Subsurface used! I'm very pleased to see that something that took me several weeks to develop (the widget is less than 200-lines long, but I needed a great deal of time to figure out what was the nicest way to highlight text, and how to implement it properly) is used, and used in a program started by nobody else than Linus Torvalds.

  So, if anyone wants to develop something : don't hesitate to do it! Even if it is a small widget or a toy application, what you develop may be of use to someone else, and it's always a great pleasure to see that code we have developed gets used by other developers.

• The End of the Google Summer of Code

  Published on mer 25 septembre 2013 in Nepomuk, (Comments)

  The GSoC coding period has ended last Monday. In this blog post, I will summarize what I have done during the summer, to give a general idea of what you can expect from a future version of Nepomuk, if my work is accepted by the Nepomuk maintainers.

  The source code of the first two projects is available in the steckdenis-gsoc2013 branches of the nepomuk-core and nepomuk-widgets Git repositories. The browser plugin can be found in the scratch/dsteckelmacher/nepomukintegration.git scratch repository.

  The Nepomuk Query Parser

  The first part of my GSoC project was to implement a new user query parser for Nepomuk. This parser is responsible for translating queries entered by the user into a formal representation suitable for querying the Nepomuk database.

  Project Goals

  The current version of the parser (that is used for years now) is based on regular expressions. It recognizes a language close to what you can use on Google ("foo -bar title:something"). At the beginning of the project, Vishesh Handa explained me that this parser has limitations (it is not able to parse file sizes, and its parsing of date-time is a bit special, the parser tries many formats in an arbitrary and locale-independent order), and that its syntax is not very user-friendly. We agreed on implementing a parser that has a syntax more close to natural language, a syntax simple to understand and that doesn't require the user to read a big book before being able to perform queries.

  The "new" query parser, as I name it, is based on pattern-matching. My first idea was to implement a real parser using state-of-the-art parsing techniques like Abstract Syntax Trees and a formal grammar, but these kinds of languages are not very user-friendly and are more suitable for programming languages, or anything that must have a precise sense of correctness and a defined meaning. The new parser aims for being user-friendly and accepting anything the user can enter, without the possibility of a parse error.

  Recognizing Human Writing

  During the spring, I developed a human date-time parser, that is to say a parser for date-times expressed like "first week of last month". Parsing such strings can nearly be considered as artificial intelligence, a field that greatly interests me. The way a human understands what is said or written always bothered me.

  The literature regarding this subject is very rich, and complex algorithms can be used. More simple ones are possible when less precision is needed, and parsing search queries doesn't need a huge amount of precision. This allowed me to simply consider that as humans learn a language by memorizing the signification of words, the structure of sentences, and how patterns map to a signification ("X's Y" = "the Y of X" = Y.owner: X, X.has: Y), a computer could do the same.

  I therefore implemented the date-time parser as a pattern-matcher. The parser considers the full string, and tries to find information in it. When words are matched against patterns, they are removed from the string. This way, the string contains less and less information, and the parsing stops when everything is removed. For instance, "first Monday of last month" contains two pieces of information : we talk about the first Monday of something, and this something likely is last month. The parser simply ignores everything it doesn't understand. A human confronted to a language he or she doesn't completely understand also works this way : a complete sentence is understood as "Warning, ... due to works ... metro stopped ... we apologize ...".

  Matching patterns

  As the date-time parser worked fairly well, I used the same algorithm for the Nepomuk query parser. The user query is split by words (if the user's locale doesn't separate words, the query is split by characters), that are used to build Nepomuk terms. At this step, the query looks for documents containing everything you typed. The query is already valid.

  Next, the parser tries to recognize patterns, that are fully translatable (the order of the words can be rearranged, synonyms are handled, and multiple patterns can be associated with the same meaning). When a pattern is recognized, placeholders are used and the pattern is replaced by its parsed meaning. For instance, "tagged as X" is recognized in "Nepomuk, tagged as Important", and is replaced by a property comparison.

  Because matched patterns are replaced with their parsed value (and not discarded as in the date-time parser), patterns can be nested. For instance, "size > 2M" contains three patterns: "2M" that is replaced by "filesize=2000000", "> comparison" that is replaced by "filesize>=2000000", and finally "size comparison" that is replaced by "nfo:fileSize >= 2000000". This also works for nested queries. A pattern like "related to %% ," matches "related to" followed by any number of terms, then either the end of the string or a comma. The terms matched by %% are all fed to the C++ rule implementing the pattern, that can concatenate them in a AND and use them as a simple value for a relatedTo comparison.

  When every possible pattern has been tried, the input is considered to be parsed and is returned to the caller. The parser did its job.

  What is a bit special with this parser is that matching patterns looks like matching regular expressions. Sure, patterns are more specific than regular expressions (and to be complete, regular expressions can be used in patterns, so that the translators do not need to explicitly write the dozens of forms a word can take in some languages), but it's the same spirit. This parser, even though not based on regular expressions anymore, and more robust, is not following a precisely defined syntax. It's up to the translators to write rules (the syntax is very simple), and each language can have its own "syntax". I find that way more user-friendly than a syntax fixed in stone.

  The Query Builder Widget

  The second part of the project was to implement a query builder widget. This widget is responsible for helping the user to enter queries. The first help is syntax-highlighting: the widget highlights what is recognized by the parser, so that the user can discover that things like "modified last week" (yes, I ported the human date-time parser to the new infrastructure) is understood by the parser and can be used when needed. The second help is auto-completion: the widget shows what patterns correspond to what has been written. For instance, entering "tagged" yields "tagged as ".

  There is no complex (or boring, depending on your point of view) algorithm to explain in this part. The code is simple, and what took time was to design a user-friendly widget that is actually useful without getting in the way of the user. A picture is worth a thousand words:

  

  And in French:

  

  A Firefox and Konqueror Plugin Indexing User Emails

  At the middle of August, most of the first two parts of my GSoC project were nearly completed. The rest of the coding period was dedicated to bug fixes (there were many small and difficult-to-fix bugs that only happened on select queries). I also added unit tests for the parser, and I submitted a patch to Dolphin to use the query builder widget in it (see the screen-shot above).

  The problem is that it is impossible to write unit tests during a full month, especially when the project tested was developed during two months. I therefore decided to find something I could do and that would benefit to Nepomuk.

  I stared with the observation that many users, even my Computer Science class mates, use webmails. Nearly nobody use desktop mail clients anymore, and it is a shame given how useful they are. Moreover, people that use mail clients, even on Linux, don't all use KMail (there are GNOME users or KDE users that are used to Mutt or Thunderbird, or that simply don't want to use KMail). This observation made me think that only a small portion of the KDE users have their mails indexed in Nepomuk (by Akonadi), and therefore that email-related queries enabled by the new query parser are of no use to the others.

  The goal of my project was to seamlessly allow these users to enjoy the features of Nepomuk. I did not want to oblige them to enter personal identification data (like POP/IMAP account names, servers and passwords) every time they open their KDE session or at the installation of their Linux distribution. Everything had to be completely transparent, without the need of any password.

  The only solution I have found is to develop a browser plugin that monitors the activity of the user and recognizes when he or she is visiting a webmail. When it is the case, a webmail-dependent Javascript snippet is run to extract the mails displayed on the page. Currently supported webmails are Yahoo! Mail (in French), Roundcube and Outlook. GMail can also be parsed but its insane use of AJAX and asynchronous queries make it difficult to detect when the page has changed, and when the parser must be re-run on it.

  A nice side-effect of this project is that Nepomuk is now able to index e-mails handled by Thunderbird or any other mail client, because I implemented a MIME/mbox file indexer.

  More information about this project, that is still in an experimental state, can be found in this blog post.

  Future Work

  I now have a KDE Developer account, and I want to use it to improve KDE. My studies require a fair amount of work, but I will try to work on two projects that interest me:

  • As suggested by Vishesh Handa, Nepomuk needs a good MS Office file indexer (able to parse the old binary formats still widely used). I have seen in the Calligra source code that a library able to parse these files is available, and I will try to use it (at least to extract the plain text content of the files).
  • The pattern matcher I use in the query parser could be useful to other projects. I will see if it is possible to split it out of Nepomuk (or to develop a standalone version) and to make it available as a shared library, that could be used by other applications. The date-time and miscellaneous parsing passes (like the recognition of numbers and file sizes) will be available in this library, as they can be useful. I hope that people will be able to develop interesting applications with this parser.

  So, stay tuned, and you can monitor my blog for activity on other projects (Planet KDE only shows blog posts related to KDE).

• A Nepomuk Integration Plugin for Firefox

  Published on ven 06 septembre 2013 in Nepomuk, (Comments)

  Since the beginning of August, I'm experimenting with the idea of integrating Nepomuk and the most used web browsers. I started with a Konqueror plugin that detects when the user is reading an e-mail on a webmail in order to index the e-mail in Nepomuk. That was quite a challenge, but I'm now able to detect e-mails on Outlook, Yahoo! Mail, any Roundcube-based webmail, and GMail will come shortly (this webmail is very difficult to parse).

  I chose Konqueror because I largely prefer to develop extensions in C++ (a compiled language with clear APIs, and the wonderful auto-completion of KDevelop), and I didn't want to fight with webmails and with Javascript at the same time.

  The Firefox Extension

  This week, I ported the Konqueror extension to Firefox. You can find it in my scratch repository. The extension can be found in the firefox/ directory and is currently unpackaged. If you want to get a proper .xpi file, just do the following:

  1 2	cd firefox/ zip -r ../nepomukintegration.xpi *

  After having installed this extension, you can begin to visit webmails. Outlook currently works best (I don't know how it is possible, but the HTML code is very well designed and crystal clear). You need to open e-mails to have them indexed, as the extension has no way to know the content of emails if you don't open them.

  When you have read some emails, go to /tmp/kde-YOU/ and look for .mime files. If you open them (using KWrite for instance, the MIME format is very human-readable), you can see the content of your e-mails. There will be no "Date" field as I haven't yet figured how to implement this C++ function in Javascript:

  1 2 3 4 5 6

  QDateTime stringToDate(const QString &string, const QString &format, const QString &language) { QLocale locale(language.toString()); return locale.toDateTime(string, format); }

  You can also download files using Firefox. Every download is represented by a .webaction file in your temporary directory. This file starts with "DOWNLOAD" (more actions will be possible in the future, like "BOOKMARK" or "HISTORY"). The next lines are the website on which the file has been downloaded, the URL of the file, and the path where you downloaded the file.

  Integration with Nepomuk

  Now that your temporary directory is full of files that describe your web activity, you can pull the steckdenis-webindexers branch of my Nepomuk-Core repository. Build this Nepomuk-Core and install it where you have your KDE developer installation. Now, go to your temporary directory and type something like that:

  1 2	nepomukindexer 8767d79459fbc4720083d06bed365236.webaction nepomukindexer 88d86afe9938e87aa3324e3cd6ff8a55.mime

  These two operations index the data that Firefox have just extracted in Nepomuk. You can also ask Nepomuk to watch your temporary directory and to index files in it automatically when they appear (this can be done in the "Desktop Search" configuration module). The result is as shown below:

  

  Conclusion

  First, I want to precise that the indexing of downloads is based on work by Martin (for the Firefox part) and Vishesh (for the Nepomuk part). I'm only responsible for gluing the Firefox part in my Firefox add-on and for adapting the Nepomuk part as a Nepomuk File Indexer.

  This ends my experiment of indexing e-mails in Nepomuk. This experiment started because I thought that it would be good to allow users that use webmails to enjoy the niceties of Nepomuk. Not everyone uses KMail, that already index everything in Nepomuk.

  If I remember correctly, the GSoC ends in two weeks. What I will try these coming two weeks is to merge my work in Nepomuk (the query parser and the query builder widget) and in Dolphin (I have a small patch that makes Dolphin use the new query builder and that I would like to merge if a future Dolphin version is planned). I will also propose this experiment for merging. The Nepomuk part is not invasive at all (I just added three file indexers : MIME/MBOX, vCard and web actions), and the Firefox add-on just have to be uploaded to Mozilla Add-Ons.

« Previous Page 4 / 6 Next »