For a while Qt has been offering qmlls, a Language Server Protocol implementation for QML. This allows popular text editors like Kate (and some lesser known ones like Visual Studio Code) to work with QML code without having to write dedicated support for it.

Naturally many people are eager to use it to hack on KDE code. When trying to do that you probably have encountered some frustration with things not working as expected. So what’s going on there, and how can we make it work?

First and foremost one must mention that qmlls is still under heavy development. There’s a number of things missing that you’d expect from a fully featured LSP implementation. If you encounter something that looks like it should work but doesn’t, don’t hesitate to file a bugreport.

So how does one use qmlls? In Kate it should be activated out-of-the-box when opening a QML file. If that doesn’t work you might need to tweak the LSP-Client settings. For other editor please consult their documentation on how to enable LSP support.

One problem you are likely to encounter when using qmlls on KDE code is that it fails to find KDE-provided QML modules like Kirigami. This happens when the modules are installed into e.g. ~/kde/usr, which isn’t searched by Qt. One way to get around this is to build and install your own Qt into ~/kde/usr too, since that way the modules will be installed into the same prefix as Qt and Qt will find them. While building your own Qt is a worthwile thing to do in general it’s not a very satisfying solution. I hope we can find a better solution for this soon. See here for a related bugreport.

If your installation is set up in a way that qmlls can find the KDE-provided modules you might still encounter it warning on unknown modules or types. In order for qmlls to show information for a module the module needs a qmltypes file. These files provide machine-readable information about the types that the module exposes. The easiest way to make these available is porting the module to ecm_add_qml_module and declarative type registration. This was done for many KDE modules already, but there’s still a number of them missing. Help on that is very welcome! Something that isn’t obvious is that in order for the tooling to work correctly module dependencies need to be marked explicity via the DEPENDENCIES parameter in ecm_add_qml_module.

If all the modules and types are found correctly you will still encounter some warnings, but most of these should correspond to actual issues and non-optimal practices like using unqualified property lookups and context properties. qmlls is a great tool to guide you towards resolving those and thus modernizing and optimizing the code. There are however some classes of warnings for which we don’t have proper solutions yet:

• Our translation functions, i18n and friends, are considered unqualified lookups by qmllint/qmlls. This is because they are magically injected into the engine at runtime. It’s not clear how a solution for this could look like.
• When writing KCMs we expose the module’s C++ class via the kcm context property, which is opaque to the tools. A different approach is needed.

Despite the current limitations qmlls is already a very useful tool for working on QML code, assuming the project is set up properly.

Happy QML hacking!