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:
cd(Pkg.dir("QML"))
include("example\\gui.jl")
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
Caveats
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.
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.
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
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!
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.
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
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.
