Latest posts

• Google Summer of Code 2014: QML/Javascript language support for KDevelop 4 and 5

  Published on lun 18 août 2014 in Nepomuk, (Comments)

  Hi,

  Today is the end of the Google Summer of Code 2014 coding period. This year, I added support for the QML and Javascript languages in KDevelop. Both languages were added at the same time because QML is a superset of Javascript (one can embed JS snippets in QML files).

  This has been a very exciting project. I started working on it on March 9, 2014, a bit before the community bonding period started, and I added features for nearly six months since then. The QML/JS language support for KDevelop (which lives in kde:kdev-qmljs, branch kde4 for KDE4 code, branch frameworks for KF5) is now complete and functional. Sure, there are always features that can be added (and I give some examples at the end of this blog post), but Javascript and QML files are now reliably parsed, and several developers already use the plugin. A released version may come shortly.

  Features

  Here is a list of screenshots, each with a short description, listing the most important features of the QML/JS plugin. This list is intented to be a summary of what have been developed during the GSoC period, so that the users know what they can expect from the plugin. This is a list of features available in both the KDE4 and the KF5 version of the plugin. The screenshots come from already-published blog posts, so please forgive me if something does not look exactly as it is now :-) .

  Type inference of function parameters when a function is called. This is needed because a function usually does not assign a value to its parameters, so normal type inference cannot be used.

  

  Function call-tips, with the name of the parameters and best matches:

  

  Field members and array members:

  

  Understanding of complex Javascript features like prototype-oriented programming:

  

  Javascript "classes" and import of Javascript files in QML (this screenshot actually shows many features :-) ):

  

  And it also has support for Node.js modules (thanks to Àlex Fiestas who repeatedly asked me for this feature):

  

  Support for ECMAScript and DOM types (QML/JS understands as many DOM types as Webkit, from which I've taken the .idl description files):

  

  KDevelop can now display a list of QML properties:

  

  When you write a signal handler, the parameters of the signal handler are part of the current context:

  

  Some helper widgets allow you to quickly enter a QML property value:

  

  KDevelop 5 features

  KDevelop 5 being based on Qt5 and KF5, more features become possible. For instance, the QtQuick.Controls module allows the QML/JS plugin to display a nice font chooser (that is a read-only font preview in KDE4):

  

  A new "problems" infrastructure has been added. QML/JS now displays problems when it is absolutely sure that there is something wrong (a mismatch between QML types when both types are sure, for instance, or a missing imported module, so that the user knows why some symbols are not resolved properly):

  

  Code-completion for Node.js require statements:

  

  Future plans

  The official coding period is now finished. It has been a wonderful experience and I had the occasion to meet many interesting people. I would like to give many thanks to Sven Brauch, my mentor, who has helped me understand the KDevelop code-base. His Python plugin has also been a great inspiration for me. I'm unable to remember how many times I thought "I don't know what to do, let's see what Python does".

  Other people also greatly helped me. For instance, Aleix Pol gave me advice at the very beginning of the coding period and at the very end (just now, in Randa!), Milian Wolff carefully reviewed most of my commits and review requests and was of great help when I had problems with the most internal parts of KDevelop, and Kevin Funk (who worked on kdev-clang for his GSoC) fixed many annoying bugs in KDevPlatform. I also thank every early user of kdev-qmljs who posted nice comments on my blog, encouraged me, and asked for features. Special thanks for Àlex Fiestas without whom half the features of QML/JS would not exist.

  Regarding the future, I'll start by being honest and say that I need some sleep. I've worked more than full-time for six months, in addition to the university, because I can't stop working when I'm excited by what I'm doing. Now I need some days of rest, and I will also work a bit on the Baloo query parser that needs some love in order to be fully usable. It is already ported to KF5 and interesting things are coming, more on that (with screenshots) in a couple of days :-) . After that, I'll continue working on what I like: Baloo, KDevelop (QML/JS and other things), and api.kde.org.

• Randa: Meeting many people and working together

  Published on mer 13 août 2014 in Nepomuk, (Comments)

  The Randa Meeting 2014 is all about having tens of KDE developers and contributors hacking together in the mountains of Switzerland. While we enjoy the wonderful food and the impressing surroundings, this meeting is also the perfect place for new features and new ideas. Even more importantly, people from all around the world and from all the KDE sub-communities are very close to each other, and we can in fact hear what people are saying in the other rooms.

  Being this close to each other is wonderful because it allows a very fast and very efficient sharing of ideas. This blog post will list several features that were implemented in the past days and that concern the KDevelop team, and you will see that they are very diverse.

  KDevelop 5 on Windows

  

  The KDE On Windows team is doing an amazing work and they managed to port KDevelop 5 on Windows. KDevelop 5 works, along with all the frameworks and other libraries on which it depends. This means that Windows now has a complete and feature-full IDE that understands C++, highlights the structure of the code, allows navigation between declarations and their uses, knows the types of the variables, can provide code-completion for class members, variables, include files, etc. Several code-generation and refactoring operations are also possible, like renaming a class/method/variable or the automatic scaffolding of .cpp files (you write the .h file, KDevelop generates the method definitions in the .cpp file). These features are available for C++, PHP, Python and Ruby (and soon Javascript).

  KDevelop can also be used as a front-end to GDB, thus providing a first-class debugging experience, with breakpoints and inspection of variables and threads. Support for Git and other versioning tools is built-in, so you can commit/push/pull/merge/handle branches from inside the IDE, view diffs, and even have a git-blame-like display in the left margin of the code editor. Finally, KDevelop comes with all the niceties of the Kate text editor, like block-mode selection, code snippets, scripts, the Vi input mode, and syntax highlighting for 240 different programming and markup languages.

  So, this is an impressive list of features that many KDE people know about, but having all of this available on Windows, as Free Software, deserves to be enumerated in its entirety.

  KDevelop QML/JS improvements

  

  On a more personal side, I had time to improve the QML/JS language support plugin of KDevelop 5. Most of the improvements are under the hood, and one even allowed me to drop nearly 15000 lines of QML (Qt5, that the plugin can now use, provides QML module description files for all the Qt4 and Qt5 modules, so no need to ship them anymore). One visible new feature is the font chooser helper widget, that displays a list of all the fonts installed on the system. This way, you don't need to open a rich text editor or any other program that lists fonts in order to find how exactly a font is named.

  KDevelop 5 bug fixes

  Instead of working alone at home, with only sporadic contacts with other people through IRC and e-mails, I can work in a room with many other people. In fact, I'm sitting just at the left of Aleix Pol, and in front of Kevin Funk. Both are busy fixing bugs in KDevelop 5 (that we now use for actual work) so that it becomes solid and stable. The list of bugs fixed is too long to be enumerated, but projects now load correctly, tool-tips work as expected (their behavior had changed with Qt5 and we had to adapt the KDevelop code), and Milian Wolff (who is not in Randa, unfortunately) is optimizing the core of KDevelop for several days.

  Love for api.kde.org

  Sometimes, someone has a question and asks it. It also happens that, in the middle of a meeting concerning KDevelop (or any other project), somebody starts to participate and gives us his or her point of view. It is also very interesting to ask people for help or simply to discuss with them. KDE Edu people are asking KF5 Porting people for advice, and the KDE SDK group held a meeting with the KDE Book group in order to discuss how KDE should be documented.

  This last meeting was especially great because it allowed "hard-coders" (developers of KDevelop are developers targeting other developers) to meet people working on the documentation. We discovered that we have shared interests (all of us want developers to discover that the KDE Frameworks exist, that they are wonderful and can easily be used in Qt applications) and that working on the documentation is easy and rewarding.

  

  For instance, I gave some love to the API documentation of the frameworks. The main page has not yet changed, but each framework now has a nice box that gives information about who is the maintainer of the framework, how to use it using CMake or QMake (yes, KDE Frameworks can be used in QMake projects), what is its mailing list and IRC channel, a Git clone URL, and a link to the freshly-released Inqlude repository of Qt libraries.

  The changes are already partly online, but api.kde.org is regenerated only once a day or so. Some features and bug fixes (like links to lxr.kde.org for each documented class) will therefore appear only tomorrow.

• QML/JS ported to KDevelop 5

  Published on dim 10 août 2014 in Nepomuk, (Comments)

  Usually, I start my blog post with a small text, but today I'll show you a screenshot:

  

  This screenshot shows the QML/JS KDevelop plugin working as usual, highlighting declarations and uses, finding types, and displaying nice tool-tips. The code-completion also works even if it is not visible on the screenshot. What is interesting is the look of KDevelop: do you see the flatter theme? The colors that are a bit different than usual? This difference is appearance comes from the fact that this is not the usual KDevelop, this is KDevelop 5, based on Qt5 and on the shiny new KDE Frameworks 5.

  The KDevelop team has done an amazing job and KDevelop works very well in its KF5 version. In fact, I'm using it right now, on real code. What is new is that the QML/JS plugin now also works on KDevelop5. I'm at the wonderful Randa meeting, and with the help of several KDE developers, I was able to very quickly port the QML/JS plugin to the latest KDevelop. You can find the KF5 version of the plugin in the frameworks branch of kde:kdev-qmljs.

  Now that all the power of Qt5 and the KDE Frameworks 5 is available, new features will be possible. They will mostly concern the helper widgets (that will finally start to be useful, for instance by displaying a font dialog allowing you to choose a font family instead of guessing (or opening LibreOffice to see the list)), but having the plugin based on Qt5 will also enable the recognition of Plasma 5 QML packages installed system-wide. In fact, this support was not possible before because the system-wide path in which those plugins are installed is only known to Qt5, and has to be retrieved using QCoreApplication::libraryPaths. The plugin therefore needs to link against Qt5 in order to use this method.

  Here are some more screenshots, showing the helper widgets ported to QtQuick 2 (and QtQuick.Controls, providing the slider):

  

  

  It is only the beginning of the Randa meeting and many more things are still to come! There are many discussions ongoing, and it is wonderful to meet KDE developers in real life and to talk with them. Exchanging ideas is very easy (it basically consists of shouting a question across the room), and we get the occasion to discuss with people working on very different projects. This is very interesting!

• The DOM and your wish-list

  Published on mar 05 août 2014 in Nepomuk, (Comments)

  This week is the last of the "active coding" period of the Google Summer of Code. On Monday 11, students should stop implementing features and start documenting things, fixing the remaining bugs and ensure that everything is working.

  I don't have a huge list of new features to present this week because I had to fight a very nasty bug (and it is still not entirely resolved), but here is nevertheless an addition to the QML/Javascript language support plugin for KDevelop that may be quite useful to a lot of people: support for the Javascript DOM.

  The Document Object Model

  Last week, I added support for Node.js modules. I did that because several users of the QML/JS plugin told me that they regularly work on Node.js code. This week, despite a bug that makes the unit tests fail (but not the real-world KDevelop), I decided to add support for the Document Object Model of Javascript, so that web developers have their scripts fully supported by KDevelop. As libraries like jQuery also rely on the DOM, having it supported is a good thing.

  The DOM is really huge and contains hundreds (if not thousands) of classes. Each HTML element or CSS property has its own class, and there are even classes for things like cookie handling, message passing between web pages, XmlHttpRequest, etc.

  I was not very fond of the idea of writing Javascript description files for all these classes. Luckily, I received an unexpected help here: Webkit (the web engine) also has to support these classes, and instead of implementing them directly in Javascript on C++, it ships files having a .idl extension. These files describe the API of the different classes and look like this:

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

  module window { interface [ ...ignored... ] DOMWindow { attribute [Replaceable] BarInfo locationbar; attribute [Replaceable] BarInfo menubar; attribute [Replaceable] BarInfo personalbar; attribute [Replaceable] BarInfo scrollbars; attribute [Replaceable] BarInfo statusbar; DOMSelection getSelection(); [Custom] DOMWindow open(in DOMString url, in DOMString name, in [Optional] DOMString options); } }

  The statements between brackets are hints for the Javascript binding generator and can be ignored. What is interesting in those files is that the attributes, methods and arguments are all named and typed. This means that no information is missing! I just had to write a Python script that parses one of these files and produces a .js equivalent, and I was able to add support for all the DOM.

  This morning, I've pushed a big commit to the kde:kdev-qmljs repository. It adds more than 10000 lines of .idl and .js files (I ship the IDL files so that looking at them and possibly modifying them is easier, but their real origin is Webkit). The Javascript file describing the DOM is approximately 4000 lines long and takes a bit more than two seconds to parse. In order to keep it to a reasonable size, I skipped the Canvas classes, the HTML classes (having Element is enough, no need to have HTMLLink, HTMLParagraph, HTMLSpan, etc), the File classes (web storage), the XML parser classes and several other ones. They are rarely used and would have made the description file far too big and too slow to parse. I can still add these classes if many users need them, though.

  Here are now some screenshots:

  

  Creating a DOM element.

  

  Code-completion for DOM classes.

  

  Code-completion for global variables and functions (that are in fact members of "window", yes, "window.alert()" works in JS).

  Finishing touches and wish-lists

  The DOM was the last big feature planned for the QML/JS plugin. In fact, I'm very happy to have been able to go this far in the project. My original GSoC proposal was entirely oriented towards QML, with only basic support for Javascript (just enough for Javascript snippets to be usable in QML files).

  I've still some bugs to fight and some things to improve. For instance, having "class HTMLElement inherit Element" displayed in the navigation widget instead of "function HTMLElement()" could be a nice addition. Allowing the user to add include paths (for Node.js and QML modules) could also be great, because some QML modules are not installed at the same place as the others.

  But what I would really like to do is to implement what daily QML developers may want. I have posted a message on the plasma-devel mailing list asking which features Plasma developers (regular QML users) may want. I've already got some hints, but don't hesitate to tell me what you would like to have implemented in kdev-qmljs. I will also be in Randa, and while most of my time will be dedicated to porting the QML/JS plugin to KF5, I will also try to listen to the wishes of everyone present.

• Node.js support in KDevelop

  Published on ven 25 juillet 2014 in Nepomuk, (Comments)

  This is a quick blog post to say that I'm working on support for the Node.js framework by the KDevelop QML/JS language plugin. The first part of my work is already finished: "require" is properly recognized and Node.js modules are properly looked-up and included. The "exports" and "module.exports" identifiers are also recognized and allow Javascript files to export symbols and to be used as modules. This means that you can now edit Javascript files using Node.js and have most of the modules recognized, included and parsed.

  The second part is writing huge Javascript files for the built-in Node.js modules. "http", "buffer", "fs", "url" and many other modules exist only as part of Node.js. There are Javascript files for them in the Node.js Git repository, but these files don't allow the QML/JS plugin to infer the types of the methods. They are also fairly big and would need a big cleanup in order to be fast enough to parse.

  As with ECMAScript, I solve the problem by shipping with QML/JS stripped down versions of those files. These files describe the classes, methods and attributes of each module, and follow a very simple format. This code is not designed to be run, only to be parsed by the QML/JS plugin, that will discover the types of the function parameters and their return type.

  1 2	exports.spawn = function (command, args, options) { return new exports.ChildProcess(); }; exports.spawn("", [], new Object());

  Writing all these files is tiring and will take some time (in fact, I'm writing them for a bit more than one day, now). So, there may be fewer commit than usual in the QML/JS repository, but I hope that this feature will serve many users. Here is a teaser of what is coming (note that functions are now listed in a way more human-friendly form):

  

  Once this feature is finished, I will concentrate my efforts on the QML code-completion. I'll also experiment with the KDE Frameworks 5 (and the KF5 version of KDevelop), because I'd like to offer a KF5 version of the QML/JS plugin. The reason is twofold: Qt5 offers the wonderful QtQuick.Controls module (it will allow me to implement many navigation widget, that will assist the users in choosing a font family, configuring and previewing animations, etc), and early KF5/Plasma5 adopters may be well pleased to be able to use the latest and greatest KDevelop on their latest and greatest environment, while still being able to work on QML and Javascript files.

  UPDATE: Here is an additional screenshot that shows that child_process.ChildProcess is correctly recognized, and that it correctly inherits from event.EventEmitter (you see that addListener is in the list), which in turn inherits from Object (there is an "assign" method at the very bottom of the list). Having all of this working was a bit more difficult than expected, but now function prototypes and class inheritance seem to work.

  

• QML binary modules

  Published on dim 20 juillet 2014 in Nepomuk, (Comments)

  Developing a new project is usually done in two phases: first, the most important features are added, and the feature list of the project quickly grows. Then, the features need to be polished, bugs fixed, and the overall usability of the project improves slowly. This second phase is often considered less interesting than the first one, but personally, I like to fix small annoyances. Fixing them makes the difference between an experimental project and one that can be reliably used by real users.

  During this GSoC, I try to work in small steps, implementing a big feature and then improving it, then implementing the next feature, and so on and so forth. This works quite well and allows me to keep a high motivation in what I'm doing: implementing a big feature is exciting but also exhausting, and improving existing features mainly consists of many small and easy commits that each have a noticeable effect. This week, I'll talk about one major feature and several small corrections that I've implemented for the KDevelop QML/JS language plugin.

  The fixes

  Javascript has no syntax to express that "this function is a member of this class". It is not directly possible to use something like function Class.method() as in C++. Developers are therefore obliged to declare class methods using function expressions:

  1	Class.prototype.method = function (a, b) { return a + b; };

  The fact that method is assigned a function has an annoying implication for the QML/JS plugin: when method is declared, it is a simple variable, a member of Class that can contain anything (a function, an integer, etc). This means that method is declared as a Declaration, not a ClassFunctionDeclaration. This is not really a problem, but this prevents KDevelop from displaying the right icon alongside the methods:

  

  The solution is quite simple: when a Declaration has a function type (when it is actually a function), then the QML/JS plugin ensures that a function icon is displayed. An icon may seem unimportant, but such a bug is very easy to fix (one or two lines), and not fixing it would have immensely annoyed all the users of the plugin.

  

  The other small feature that I've added is support for the __proto__ member of Javascript object instances. This member is used by several Javascript libraries and may also be used in a couple of QML files, so it is not going to be useless:

  

  Other small bugs have been fixed. For instance, in a QML file, typing ANamespace. lists the components declared in the namespace, and nothing else (previously, there was some garbage, for instance the namespaces imported by ANamespace, or the built-in Javascript classes). Code-completion for import statements is now way more useful, but more on that later.

  Binary QML module imports

  Back to the QML world. The goal of my GSoC is to have the best possible QML support in KDevelop, because KDevelop is already the best-in-class IDE for C++ Qt development, and only lacks a good QML support. Javascript, on the other hand, already has many great IDEs and competing with them may be a bit out of the scope of a GSoC project.

  My strategy to have great QML support in KDevelop is to concentrate most of my efforts on this language, while still having a robust enough Javascript support so that Javascript snippets in QML files work as expected. For instance, Javascript built-in classes were added because many of them are used in QML files.

  So, this week was dedicated to importing QML binary modules and QML installed modules. First, some definitions:

  • QML installed module: QML module that is installed on the user's system, for instance by a KDE package. Unfortunately, QML does not have system-wide include paths as Python and Ruby do, each QML application provides its own search path. Luckily, most QML applications either use only Qt-provided modules (and they have been supported for a long time now), or use KDE-provided ones. KDE installs all its modules in /usr/lib(64)/kde4/imports, so they are quite easy to locate. An installed module consists of a directory that contains .qml files and possibly .so files. The library files (that can be mixed with plain .qml files) contain additional native components, implemented in C++.
  • QML binary module: Library that contains QML components. The .so files I was talking about hereabove are QML binary modules.

  Supporting QML installed modules was quite easy: KDE's KStandardDirs allows me to easily locate them, and the infrastructure for importing whole directories was already in place.

  Binary QML modules were a bit more difficult because they need to be dumped before the QML/JS plugin can use them. Dumping a binary module file is the action of running qmlplugindump on them, a tool provided by Qt that takes a .so file and writes a QML module file for it. The QML module file is a valid QML file and can be parsed by the plugin.

  With directory imports working, binary QML modules dumped and the dumps correctly parsed, the all the pieces fit together:

  Uh oh! A .so file!

  Enter qmlplugindump (the file is cached for later reuse)

  Components exported by Plasma Core

  Members of a binary QML component

  Finally, as an added bonus, I've improved the code-completion for import statements. They now list only the imports that start with what the user has already typed, and they handle installed modules:

  

  Testing the QML/JS plugin on real QML files has shown that QML is very nicely handled, even if there are still some small glitches (for instance, several built-in QtQuick 1.0 types and properties are still missing). Sven Brauch will also send me a list of places where the code-completion could be more useful. In fact, don't hesitate to tell me which features you would like to see implemented, I've still four weeks ahead of me!

« Previous Page 2 / 11 Next »