QML.jl first release

Hi all,

I am pleased to announce the first release of QML.jl, a package to interface with the Qt5 QML GUI toolkit. Feel free to try it out and leave feedback.

Main features

  • Standard mechanisms for exchanging data with the QML side, so all the QML widgets are available and can be fed with Julia data
  • Julia Display support, using PNG only for now (see plot.jl example)
  • ListModel to use Julia arrays as models for ListView and so on (see dynamiclist.jl example)
  • Support for ModernGL.jl (see gltriangle.jl example)
  • Preliminary (i.e. no mouse events in the viewport yet) support for GLVisualize.jl (see glvisualize.jl example)
  • Tested on Linux, macOS and Windows
  • The inherent QML features, including clean separation of GUI and backend and a high-quality native look.

Note, the easiest way to run the examples on Windows:


How it works

QML is accessed through some custom C++ classes that use the standard Qt5 C++ API and are exposed to Julia using CxxWrap.jl. In fact, the whole package started as a proof-of-concept for CxxWrap following this thread, but it got out of hand :wink:


  • Fedora dependencies installation was broken in the tagged release, so you should do a Pkg.checkout or manually install qt:
    sudo yum install cmake qt5-qtbase-devel qt5-qtquickcontrols qt5-qtquickcontrols2-devel
  • There is a build error on Windows, but it’s a harmless typo and the package works after installation anyway
  • To run the glvisualize example, you need to checkout GLWindow after adding the GLVisualize package.

I just tried this on a “clean” Windows 7 machine, and it didn’t work because the Visual C++ Redistributable was missing. It can be installed from here:

@tkelman Would it be acceptable to distribute those DLLs with the CxxWrap binaries? The “proper” way seems to use a merge module in the installer, but that is of course not applicable to a Julia package.

1 Like

Doesn’t Qt have a mingw build that would avoid these issues? Unless someone’s paying you to care about visual studio, you should probably avoid it.

On Windows 10, mingw is no longer in the officially supported list:

Mingw would probably work anyway, but I prefer to avoid it:

  • Combined with CMake, Visual Studio is a much more pleasant experience on Windows than MinGW, not the least in terms of compilation speed (minor issue at the current project size)
  • VS is the standard development tool on Windows, it will be familiar to a much larger portion of the audience. Being able to use it to compile this package is more encouraging to get contributions
  • I was under the impression (could be wrong though?) that the largest portion of the Julia userbase is on Windows, so I prefer to put in a little effort to make the package usable for the largest part of the audience. In the end, it’s pretty easy to do with CMake
  • VS, for all its faults, gave valid compilation errors that both clang and gcc overlooked, so multi-compiler use improves the code
  • Appveyor works out of the box, all dependencies are installed and it can just compile and test both CxxWrap.jl and QML.jl. I don’t know if that also applies for mingw.

Finally, no, I’m not paid for this, in fact the only time I use Windows for non-gaming activity is to test my packages and build their binaries :slight_smile:

MSVC is not supported for use with Julia. Its lack of required functionality for many scientific libraries is a strong argument against your first point. While it might work some of the time to use it in packages, you’re fighting against the way the language and almost every binary package that I’m aware of is built. Mixing compiler runtimes is a bad idea. If you prefer MSVC, then you should work to make MSVC a supported platform for Julia itself before using it in packages. There’s a pretty clear path to improving that situation, but today it doesn’t exist as something users should touch. The issues related to this are extremely quiet, so if there’s any demand in the Julia user community for better MSVC support we’re not seeing it.

The majority of Julia users are not C++ developers and very few of them have compilers installed at all (at least on Windows). Witness the pain that is building Python C extensions on Windows and the reason conda exists - all of that is toolchain inflicted.

You’re right that it’s often a good idea to try building a code base with multiple compilers, but asking an open source community that primarily develops on Mac and Linux to support MSVC at all is painful and not worth their time. GCC at least works comparably everywhere, and developers can cross compile Windows binaries for their users without having to develop on Windows themselves.

Well, I think many people are very happy to get a powerful GUI solution for Julia, that works on the three major platforms. Most of them would probably don’t mind installing the VC++ redistributable, as long as it is clearly documented how to do that. Keep up the good work!



Thanks :slight_smile:

I was holding off replying until I could test this, but here’s what I found out / plan to do after some more research:

  • The redistributable DLLs could be placed in the zip archive, legally.
  • I understand there can be issues mixing binaries, but in this case it happens through a C interface and works well, as demonstrated by the passing tests on appveyor

On the other hand:

  • Julia binaries already ship with a libstdc++
  • Should others write CxxWrap-based packages and release on Windows, they are forced to use the same compiler as I do, to ensure binary compatibility with the CxxWrap releases.
  • MSYS2 has 64-bit Qt 5.6 binaries (those are missing from the official Qt installer, which is what prompted me to stick with MSVC I recall now)
  • Appveyor can also build using MSYS2 it seems, and most of the scripting boilerplate is in fact in the Julia source tree

So I plan to:

  • try building binaries with MSYS2 and the mingw version used by Julia (hopefully compatible with the MSYS2 Qt binaries)
  • update appveyor scripts so binaries are built there and can be uploaded automatically somewhere
  • keep the MSVC tests also, to ensure it still works when/if a MSVC Julia variant appears

The advantage of this approach is that anyone using QML.jl as a template for a CxxWrap-based project will also benefit from automatic binary generation on Windows, after some adaptations to the scripts, and doing so ensures binary compatibility across all CxxWrap-based packages.

Now let’s hope all of this will work :slight_smile:

The ‘holy grail’ of UI toolkits for interpreted/JIT compiled languages is a solution that works without further compilation/linking activities and without major installations. Something like this is available with toolkits/libraries that have simple+clear C-APIs (see ccall). With this background i’d rather call Gtk.jl a powerful GUI solution that works on ‘the’ three major platforms (minus rendering problems with Fonts or HiDPI).

I’d not assume that everyone can simply install a VC++ redistributable in her/his Windows setup, even if she/he wants to.

Don’t get me wrong, i’d like to see QML or similar Qt based UI succeeding, but we’re importing too many dependencies with the current approach.

The VC++ redistributable is just a set of a few small DLLs that can be dropped into the QML binary folder and would be included in the binary download (transparent through Pkg.add). But like I said, this is no longer my preferred solution after @tkelman 's comments and some further research.

That’s simply not true: I forgot to add the VC++ redistributable DLLs for the current release, that’s all. The “many dependencies” consist of a single 36MB zip file that is downloaded automatically on Windows, or the required Qt packages on OS X or Linux (just like you need the Gtk packages for Gtk.jl). As mentioned in my previous post, I will attempt a MinGW solution since it is a cleaner fit for Julia, but in terms of dependencies the difference is negligible (the equivalent DLL is libstdc++.dll, and it comes with Julia).

Well, i might be missing something here, but QML.jl list CxxWrap.jl as requirement and that mentions:

Building on Windows

To build on Windows, you need to set the BUILD_ON_WINDOWS environment variable to “1” in order to avoid the automatic binary download. The build prerequisites are:

Cmake in the path
Latest version of Visual Studio (Visual Studio 2015 Update 2 RC with MSVC 19.0.23824.1, it won't work on older versions due to internal compiler errors)

Aha, I see that line could use some extra clarification :slight_smile:

This is just needed if you want to compile CxxWrap (and QML) on Windows, but the default is to download binaries on Windows, and then you don’t need Visual Studio or CMake.