Articles in the Nepomuk category

• Using KDevelop QML/JS in real life

  Published on mar 01 juillet 2014 in Nepomuk, (Comments)

  First of all, I'm very happy to say that I've passed the GSoC midterm evaluation! I can now continue my work on the QML/JS language support plugin of KDevelop for the rest of the summer! By the way, here is a new blog post listing many new features and bug fixes. Most of my work of the past days consisted of fixing nasty bugs (some of them took several days to fix), but I've also implemented nice things that deserve screenshots.

  QML enhancements

  As explained in a previous blog post, QML component instances inherit from an anonymous class. The anonymous base class of QML component instances has no name, and was displayed as <class>. Now, this useless information is replaced by the actual QML component from which the QML object inherits.

  

  Several missing QML components have been added, and the most commonly used "bound properties" of them have been added. These components and properties can be found in the Qt documentation but are not described in the plugin.qmltypes files shipped with Qt. I therefore had to manually edit them in order to add the missing information. Now that this is done, the famous Component.onCompleted binding is recognized.

  

  Less than 6 hours ago, I did not know that it was possible to describe in QML that a property wants to be bound to a Javascript snippet (like signals and slots). This is not used very often, but it still has to be supported by KDevelop. I represent that by giving those properties a function type:

  

  The last QML enhancement of the past days is the ranking of code-completion proposals (this is not yet in the Git repository but will land very shortly). When assigning a value to a variable, or comparing a variable with a value, or binding a value to a QML property, the QML/JS plugin will show you which code-completion proposals have the right type (or are a function having the right return type):

  

  

  Classes are highlighted in light green because they might also end up being of the correct type: assigning a bool to an int is incorrect, but a class may have a method or an attribute of the correct type, so highlighting classes allows the user to distinguish them from variables having a completely wrong type.

  User interface improvements

  A KDevelop language plugins mainly consist of a Definition-Use Chain builder (the thing that tells KDevelop where variables/classes/functions/methods are declared and used, and which types they have) and a code-completion infrastructure (that auto-completes variable names, import statements, etc), but such plugins can also customize the way KDevelop looks and interacts with the user.

  The QML/JS plugin does not change much of KDevelop, but provides a very nice feature: small widgets that appear when the user edits a property where a helper widget may help. There is a color picker widget, one that can be used to choose the size of a font, another one that helps visualize margins and spacing, etc. These widgets are currently quite limited because KDevelop depends on Qt4 and cannot use the wonderful QtQuick.Controls module, but as soon as KDevelop becomes Qt5-based, there will be widgets for choosing font families and previewing animation easing types.

  

  Oh, and the most interesting point about these widgets is that they are implemented in QML, and that they are fully supported by the QML/JS plugin! I was able to edit them entirely in KDevelop and the experience was very great: proper syntax highlighting, complete code-completion, types inferred everywhere, modules listed, etc. There are still features that are missing, like hints for function calls (showing the signature of the function you are calling as you type) but the plugin is already in a pretty good shape.

  Named module imports

  The color picker described in the above section is based on the ColorPicker component of Plasma. I simply took it and back-ported it to QtQuick 1.0. When I first read the source-code of this component, I discovered a new import syntax: import X as Y. This was not yet supported by KDevelop, so I implemented support for that. It took me two or three days and required several changes all over the place, but it finally worked!

  

  The above screenshot shows that named modules are recognized by the code-completion infrastructure, and this screenshot shows that components declared inside those modules can be used in the code:

  

  I'm going to Randa!

  I think that everyone (or nearly everyone) has already heard of the Randa meeting that will take place mid-August. During a bit more than one week, tens of KDE developers will join in the same building and work on your beloved software compilation. I will be part of them and I will work on the KDE SDK (and on how to allow KDE developers to develop in C++, QML and Javascript right in KDevelop) and also a bit on Baloo (my GSoC project of last year concerned Baloo and I'm quite familiar with the code base, what Nepomuk was and the concepts used in those pieces of software). By the way, I invite you to help make this meeting possible by joining the fundraising campaign.

• Now come the holidays!

  Published on jeu 26 juin 2014 in Nepomuk, (Comments)

  Hi,

  I did not have much time to work on the KDevelop QML/JS language support last week because I had many big exams to study. Now, this is all done and I even received my results: all exams passed! Wonderful, I now have close to three months to dedicate entirely to KDE and KDevelop development.

  Even if I wasn't able to implement much cool new things this week, I was able to fix several bugs. For instance, the unit tests are now more thorough and more stable (there were race conditions that made the tests fail on some computers and on the KDE build system). One interesting feature is the support for built-in QML types. These types are documented as part of the language and are not described in any QML module file. Examples of such types are rect, font, vector3d and color (note that their names start with a lower-case letter).

  There are still missing types, because some of them are not part of any module and not documented anywhere else. They have to be discovered. For instance, QQuickAnchorLine doesn't exist anywhere, so anchors.verticalCenter is shown to have type <class>. I'll have to look in the C++ documentation of these classes and to build the corresponding QML types myself in order to have them working. It should not be too complicated.

  Today was my first "holiday" day, so I was able to fix a bit more bugs. Nothing fancy here, but syntax-highlighting now works a bit better if you change something in a document and make it unparsable. Code-completion is also disabled in comments, and Javascript (and QML) functions are now completed with braces (if you select "doSomething" in a code-completion list, "doSomething()" is inserted in the document and your cursor is put inside the braces). Last but not least, there is code-completion for import statements (module names and versions are displayed):

  

  I'm not yet happy with the result and I think it would be preferable to first show the module names (in alphabetical order, and without any duplicate). Then, when the user has selected a module, display its available versions. I think that this is how QtCreator handles the thing.

  The coming days will be dedicated to more bug fixes, and to proper handling of "property widgets" (tool-tips that are displayed for select QML properties and that allow you to visually choose a value for them, for instance a color chooser). All in all, QML supports should start to be somewhat usable, and I will try to edit big QML projects in KDevelop. After that, I will be able to work on Javascript support. For instance, function call-tips are a wonderful feature that is currently not supported (this feature displays the name and types of the parameters of the function you are calling, so that you can see what you are doing). Javascript objects, classes and prototypes are the next big chunk, that may well take most of the second half of the GSoC. It's also the most challenging and interesting part of the GSoC, and I'm eager to start working on that!

• QML module versions and automatic imports

  Published on mar 17 juin 2014 in Nepomuk, (Comments)

  This week is going to be a bit busy as I have an exam tomorrow, on Thursday and then next Monday. I still have had some time to implement cool new features for the QML/JS language support plugin of KDevelop. This blog post will not contain any screenshot because these features are not very visible, but are interesting nevertheless.

  Automatic import of all the files of the current directory

  Most Javascript developers tend to put all of their files in the same directory. This is not a problem (especially for a small application), because one of these files tend to be jQuery.js or any other Javascript library, and the others are small Javascript files specific to the website being developed.

  Several weeks ago, I told you that plain Javascript does not have import statements. This is a problem because it makes difficult to know which files the user is going to use in the source-code being edited. For instance, myapp.js may refer to jquery.js, but nothing in the code gives this information.

  The fact that KDevelop has to guess which files the user would like to have included, and the fact that related JS files tend to be put in the same directory oriented me towards a simple solution: each Javascript file imports all the others in the same directory. This way, every symbol defined in each file becomes visible to all the others. This is nice and fast, and the user can now use jQuery without having to import it.

  There is a small technical difficulty here, though: if every file imports all the others, we get circular dependencies (A imports B and C, but B imports A and C, thus A can see itself by the way of B). The solution that I used is to "copy" the declarations of every file into the others instead of importing them. This way, A doesn't import anything but contains the declarations of B, C, etc. B does the same, but uses the version of A without the declarations of B, C, etc copied. This way, A cannot see itself by the way of B, and B cannot see itself by the way of A.

  Copying declarations? And what happends if a declaration changes? What about memory usage? Those are valid questions, and I draw your attention to the fact that I've put quotes around "copy" :-). The plugin does not copy the top-level declarations of each other file, it creates alias declarations for them. An alias declaration is a declaration that points to another. For instance, "myVariable refers to myVariable in B.js". This way, if B is modified and the type of myVariable changes, A will immediately see the change. This is also a bit lighter that copying the declarations.

  I described the automatic import for Javascript files, but it is also enabled for QML files. This way, QML files can refer to Javascript methods defined elsewhere, Javascript files can instantiate custom QML components, and (more importantly) QML files can see the other QML files and instantiate their top-level QML component. In QML, if a file named MyComponent.qml describes a component, all the files in the same directory, without any import statement, can instantiate the MyComponent component. This feature is therefore very useful to both Javascript and QML developers, and was fairly easy to implement.

  Module versioning

  This feature also refers to import statements. When the user imports a QML module, a version has to be given (as in import QtQuick 2.1). This version was not used until now, but is now understood by the QML/JS plugin. If you import QtQuick 2.0, you will not see the components that appeared in QtQuick 2.1, 2.2 and 2.3. More importantly, importing QtQuick will not import a mixture between QtQuick 1.0 (Qt4) and QtQuick 2.0 (Qt5). This solves the problem that was visible in my previous blog posts: there are no longer dozens of duplicated QML components and wrappers in the code-completion popup.

  The module versioning point was quite invasive to implement and is still being reviewed. The first point is already in the kde:kdev-qmljs repository, ready to be tested.

  One last thing that I would like to have fixed before the midterm evaluation (next Monday) is the support for built-in QML types (by "built-in", I mean "part of the core language"). For instance, QML recognizes the vector3d, font, color, date, time, point and rect types, that must be recognized, highlighted as types, and some of them even have attributes (rect has x, y, width and height). This should not be too difficult: I just have to add some components to the plugin.qmltypes files of QtQuick 2.0 and QtQuick 1.0 (both need to be modified because Font has a different definition in QtQuick 1.0 and QtQuick 2.0).

• Enhancements, cleanups and fixes for QML

  Published on mar 10 juin 2014 in Nepomuk, (Comments)

  Some features take time to implement, and it's great to see them finally working. Bug fixes and incremental improvements, on the other hand, are quickier to do but less exciting when taken individually. It's only the sum of many fixes and small improvements that can make a difference.

  This week, I'll show you many screenshots because I've fixed many things in the QML/JS language support plugin for KDevelop, because Sven pointed many flaws of the plugin :-). Each fix was quick, each improvement incremental, there were no big new features like code-completion that were added, but the QML/JS language plugin is now way more useful than before, and closer to what the users expect. Let the screenshots rain!

  More QML syntax recognized

  "Object on property" is a QML syntax that allows the user to bind an object to a property. This can be used to define animations that should be played whenever a property changes ("XAnimation on property"), but also state changes and behaviors. This syntax is now supported and the user can see the properties available in the object bound to the property:

  

  You can also see in this screenshot that signals and slots are now correctly handled: signals are listed prefixed with "on" so that activating a code-completion entry will create a slot for the selected signal.

  

  Properties can be declared. Standard types, aliases and lists are supported:

  

  Signals can also be declared:

  

  Better recognition of signals and slots

  Signals and slots are an important part of QML, and need special handling. For instance, signals can have parameters that must be visible in all the slots they are connected to (the parameters shown in this picture are the ones of test(int a, int b)):

  

  Qualified identifiers and grouped properties

  A QML item, for instance a label, can have a font associated with it. Its font has several attributes, for instance the family name, the pixel size, etc. There are two means to handle that in QML, and the two are now properly supported. Here is an example of a qualified property name:

  

  And now, the syntax named "grouped properties", that can be used to configure a font quickly using font { pixelSize: 20, family: "Arial", b: true }:

  

  Basic refactoring support

  A very recent improvement of KDevPlatform has made refactoring very easy to implement. I've implemented it for the QML/JS plugin, and now you can select a variable, a function, a component identificator, a signal, or anything like that and click on the "Rename..." entry of its context menu. If you rename a variable directly in the code, KDevelop will ask you if you want all its uses to be renamed.

  

  More than these eight improvements were made during this week, but not all of them can be shown using a screenshot :-). The QML/JS is not quite usable, but two bugs are remaining and will have to be fixed:

  • QML module files declare components in alphabetical order, which is a problem if component A uses component B (as the type of one of its property for instance). There are many components that have this problem, hence the "<class>" that appears in the code-completion popup instead of the correct type of an attribute. Solving this is underway, but KDevPlatform does not like when something is used before it is declared.
  • Strangely, the Kate syntax highlighting seems to be disabled for QML files once the QML/JS plugin has parsed it. When I open a QML file, "signal" appears in bold and bright blue and "property" in bold and black. After half a second, when the plugin has parsed the file, and as you can see on the screenshots, these keywords are not highlighted anymore.

  I have many exams the coming days, so my progress will be a bit slower than last week, but I hope to be able to fix as many bugs as possible, most importantly the first one listed above. It is quite serious and prevents many things from working (Label { margins: ... } does not work because QQuickMargins is after QQuickLabel in the module file).

• Code-completion for QML/Javascript object members

  Published on mar 03 juin 2014 in Nepomuk, (Comments)

  Last week, I talked about how the QML/JS language support plugin for KDevelop started to support basic code-completion. It was able to understand QML import statements and to display the list of all the properties and methods accessible from within a QML component instance.

  This was already quite useful, but what most developers want is to be able to see the available properties and methods as they type. If "object" is of type Label, and they type object., KDevelop should display the list of all the properties and method of Label. This week, I've implemented just that :-).

  Recognizing object members

  The first thing that has to work is the proper recognition of object members in the use builder (the use builder is the part of the plugin that tells KDevelop where each variable, function or class is used; this way, KDevelop can highlight every occurence of a variable if you put your cursor on it). This was easier than expected, and the QML/JS plugin was soon able to recognize that "field" in object.field is an use of the "field" attribute of "object".

  

  Adding this support to the Javascript language needed a small additional step: "objects" in Javascript are declared like dictionaries in Python (they can also be declared using prototypes or simple assignations, but this is not yet supported). I therefore had to add support for object literals. Once this was in place, the uses were properly recognized:

  

  Code-completion of object members and array subscripts

  Finding the uses of object members is cool but is only the first step towards usefulness. As I said in the intro, what most developers want is to have code-completion items for the object they have just typed. The details of this support are a bit complex, but the general idea is to detect that the user has typed object., to remove the last dot, and then to parse the object string (that can be a complex expression, for instance func()[0].prototype. Once this string is parsed, the use builder presented above can be used to find what is the declaration corresponding to the whole expression, and if it is an object, which fields are accessible from it.

  

  The Javascript support for this was trivial (in fact, the interesting part of the code that I've shown above is in Javascript), but I added one small feature: sometimes, object members are not accessed using object.member, but object["member"]. The QML/JS plugin is therefore able to recognize the latter syntax in addition to the former one, but only when the array subscript is a string literal (it's impossible to guess that object[foo()] will represent a particular member of object, because foo can return anything).

  

  This ends this blog post. I hope you enjoyed the screenshots and the new features! It's very cool to work on all this, and KDevelop is surprisingly powerful. A lot of features appear "for free" (like renaming a variable and having a tooltip that asks me if I want all of its uses to be updated), and the features that must be implemented are easy to implement because KDevelop provides everything one can dream of. Moreover, there a now many language plugins for KDevelop (have a look at kdev-python, kdev-ruby and kdev-php, that work very well, and kdev-clang that is very promising). Having such an amount of plugins eases everything because I can look at them and discover how they have handled a particular problem.

  For the curious, here is a list of future features that I plan to implement during the following weeks:

  • Support for "this" and "parent" in QML files, and adding support for "Behavior on ..." and thinks like that (called "object bindings" in the QML jargon)
  • Fixing some bugs in how QML slots are handled
  • If I declare var a = {};, I would like a.foo = "bar" to declare a new string member of a. Same for a["key"] = false;, that would later be listed in the completion proposals of a.
  • Support for built-in JS types (String, Int, all of these have built-in methods that should be listed). This can be very complicated and I need to think about it
  • Support for function prototypes and object instantiation in Javascript. This is very interesting and I already have some ideas because I've discussed the problem with Sven Brauch (my mentor)
  • The most complex thing in Javascript: on web-pages, JS code is executed in the order in which it has been included in the HTML file. This is a problem because most web-developers start by including, say, jQuery.js, and then all of their JS scripts. The JS scripts can access all the declarations of jQuery, but nothing in those files say that jQuery has been included, and where to find it. Node.js has require, but plain JS doesn't. Maybe a special comment, like /*-- include /path/to/file.js */ may solve this problem, if developers accept to put special comments targeting KDevelop. Maybe just importing all the files of the current directory may work, but is poses the problem of "everyone sees everyone" as each file should be able to access the declarations of all the others.

• Import statements and code completion

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

  Coding is a very pleasant experience, but writing about the code is at least as pleasant, especially when there are many things to show off!

  This week-end, I finished the support for import statements in the QML/JS KDevelop language support plugin. After that, I decided to have a look at how code-completion works. In fact, one of the nicest feature of KDevelop is its code completion, and having it right is very important. This blog post will therefore explain how I implemented several features concerning the code-completion of QML files. For those who prefer to see things instead of reading a technical description of them, I have put several screenshots that show how everything fits together.

  Note that all I will show in this blog post is still very experimental and has not even yet been subject to review requests. I still need to clean up the code (and the Git history, full of commits partly reverting what others have done), and after that I hope to have all of this merged into master.

  Namespaces and import statements

  Last week, I implemented the support for plugin.qmltypes files. These files contain the complete description of the contents of a QML module, and can be obtained by running qmlplugindump on the module. This is needed because QML modules are distributed in binary form (most of them are shipped by Qt and are implemented in C++). QML does not have a notion of "header files" like other languages have, and unlike Python, the complete source-code of modules is not available.

  Parsing these plugin.qmltypes files was fairly easy as they are very complete and contain all the information needed. Moreover, they are valid QML files, so I did not have to implement a new parser for them. When the user imports a QML module, the plugin finds its plugin.qmltypes file (the plugin ships module files for all the QML modules found in Qt 5), and parses it. The module file contains many declarations (classes, methods, properties, enums, etc), and the plugin puts all of them in a namespace.

  In order for at least every C++ developer to be able to understand what I will explain, I will always show how the QML/JS parser sees things using a C++-ish syntax. This way, you don't have to be familiar with specific KDevelop concepts, like definition-use chains, declarations and contexts. You can simply think of the QML/JS plugin as a mean to convert QML into a subset of C++ that is somewhat understood by KDevelop. Note that the conversion does not have to be exact because the goal is not to execute QML in KDevelop, but only to display nice code-completion popups and have a great syntax highlighting.

  So, my first example is an import statement. When the QML/JS plugin sees an import statement, it parses the corresponding module file and puts all of its declarations in a namespace. As QML does not support namespaces (you use Button, not QtQuick.Controls.Button), a "namespace alias" needs to be used. Namespace alias are simply "using" clauses in C++.

  1	import QtQuick.Controls

  Becomes (note that namespaces with a dot in their name is not valid C++, but the DUChain supports such namespaces):

  1 2 3 4 5

  namespace QtQuick.Controls { #include "$DATA_DIR/kdevqmljssupport/QtQuick.Controls.qml" } using namespace QtQuick.Controls;

  Code completion for namespaces

  When a QML module is parsed and correctly imported, everything it declares becomes available in the current file. The previous section explained how it works, now it is time for a screenshot:

  

  A "wrapper" is a C++ class exposed to the QML world (for instance QQmlAnchors). A "component" is an actual QML component that can be instantiated. In the screenshot above, it happens that every wrapper has a associated component (for instantiation), but most of the time, the wrapper (QQmlItem) and the component (Item) don't have the same name. There is even a large bunch of wrappers without an associated component (QQmlMargins for instance, the type of "margins"; you never instantiate a margin).

  When the user uses a QML component, KDevelop is now able to display from where it comes (and even where its declaration lies in the module file, even if it is useless):

  

  Here, you see that Label is an interface inherited by Label (another one ;-) ), and inheriting from QQuickText. Why so many classes? Because QQuickText (an interface) is a wrapper around the C++ QQuickText class, Label (the interface) is the wrapper around the Label C++ class, and Label (the class) is the actual QML component. I still have to make KDevelop resolve "Label" as the component, not the wrapper, but it is a small technical detail.

  The class hierarchy

  Nice. Now the user is able to see the list of all the QML components that he/she can use. It's already very useful, but more can be done. The second new feature of the QML/JS plugin is code-completion for the signals, slots, methods, properties and enumerations of all the standard QML components. This feature is allowed by the fact that plugin.qmltypes files describe everything in great detail (it even gives the types of function parameters, and whether a property is read-only or not!)

  The problem is that using this information is difficult, because the object hierarchy in QML is a bit more complex than it looks. For instance, if I create a QML component that inherits from Button, I can see all the attributes of Button. Now, I can add new properties and attributes to my custom component. If I give a name to my button and someone else uses it, this person must be able to see the properties of Button and the properties I have added.

  Let's look at an example:

  1 2 3 4 5

  Button { id: my_button text: "Hello!" property int foo }

  Now, an object named "foo" is available, and it has all the properties of Button, plus the one that I've just declared. The QML/JS parser handles that by using an anonymous class. This class has no name and inherits from Button, and it overloads its text property and adds a "foo" property. Now, my_button inherits from this anonymous class, and everythings starts to work.

  1 2 3 4 5 6

  class __anon : public Button { string text; int foo; } __anon my_button;

  Things are in fact a bit harder than that, because "my_button" is visible in the QML component that I declare. For instance, I can have a QML component named "my_button" that contains a Loader that has "my_button" as proxy, or something like that. Moreover, QML component names are global, and they can be used even before they are declared. The parser has to handle that.

  Code completion for QML components

  Now that every QML component knows who its parents are, it is easy to add code-completion to them. The user can therefore see which properties, signals, slots, enumerations and methods are available in the QML component being edited:

  

  There is still one problem to fix: QML component instances like "my_button" in my previous example inherit from an anonymous class. This means that their type is a class having no name. By default, KDevelops identifies my_button as " my_button". This does not give much information about what my_button is :-).

  I have not yet found a solution of this problem for the tooltip shown in the code editor (but as eveything is customizable in KDevelop, a solution should exist somewhere). However, the code-completion list is fully and easily customisable.

  When the code-completion list has to display a QML component instance, the QML/JS plugin looks at the anonymous class of the QML component that has to be displayed, and replaces "" with the name of the QML component from which the anonymous class inherits. In my example, my_button inherits from __anon, and __anon inherits from Button. Instead of considering that my_button inherits from __anon, the QML/JS plugins behaves as if my_button inherited from Button. It skips over __anon.

  This ends my week-end of work. I now have to cleanup all of this and to have it merged into master. After that, I will work on more advanced QML constructs, like behaviors ("Behavior on ... { }") and animations, and more advanced code-completion (being able to type "my_button." and to see all the properties of my_button, for instance). Then it will be high time to give some love to Javascript arrays. Finally, I would like to be able to have this kind of code-completion:

  1 2 3 4 5 6 7 8 9 10 11

  Column { Text { id: text } Button { text: "Click me!" onClick: { text. // List of all the methods of text } } }

« Previous Page 3 / 6 Next »