[ANN] QML.jl v0.8

Hi all,

After a too long delay, there is finally a significant new version of QML.jl, the package wrapping the Qt QML GUI toolkit. Highlights are:

  • Switch to Qt 6
  • New JuliaItemModel that is compatible with QML TableView and ListView
  • Works natively on Wayland (thanks to the fact that we are using Qt 6)
  • Change the license to MIT

If you want to take a quick look, the following sequence of commands will download the examples to a temporary directory and launch a small test app:

import LibGit2, Pkg
cd(mktempdir())
LibGit2.clone("https://github.com/barche/QmlJuliaExamples.git", "./")
cd("basic")
Pkg.activate(".")
Pkg.instantiate()
include("gui.jl")

More info at:

13 Likes

This question is not very well-informed but maybe you can answer it.

Stata is a statistical programming application built on QT. They have a built-in table viewer which is exceptional. Super snappy, even for large data sets, which gives me the impression it’s lazy, doesn’t need to copy all the data into some other location to display it.

To what extent do you think the added tableview functionality in QML could be able to replicate something as useful as Stata’s features?

4 Likes

I have never used Stata, but this description from the QML TableView leads me to believe it should be possible:

" TableView inherits Flickable. This means that while the model can have any number of rows and columns, only a subsection of the table is usually visible inside the viewport. As soon as you flick, new rows and columns enter the viewport, while old ones exit and are removed from the viewport. The rows and columns that move out are reused for building the rows and columns that move into the viewport. As such, the TableView support models of any size without affecting performance."

I have not tested this on large data sets, however.

1 Like

A.

Why, LGPL wasn’t outputting to me, nor should be to anyone, I think. I think it was also a good signal about what your package is built on.

Don’t get me wrong, it’s not illegal to make wrappers/bindings as MIT (or some licence not same as of wrapped code, in case it’s freely distributable) for e.g. LGPL-licensed wrapped code, or even for GPL or AGPL. But without documenting clearly, for at least GPL or AGPL, such code is wrapped is I think a disservice.

A lot of users might thing it’s MIT all the way down. And I tried to track, first JLL was also MIT, but I believe you end up in:

https://docs.juliahub.com/Qt6Declarative_jll/rB4FL/6.3.0+1/

which is also MIT, but I clicked a link there leading to the Qt Company website.

Qt for sure is free software, at least for free or GPL software. And LGPL would be for all, if that’s all there is to it. I don’t see how the company can have a real leverage to force you to pay them. But they at least want that, and make it obscure (to me) that you can’t skip that.

(iv) Applications may not pass on functionality which in any way makes it
possible for others to create software with the Licensed Software;
provided however that Licensee may use the Licensed Software’s
scripting and QML (“Qt Quick”) functionality solely in order to enable
scripting, themes and styles that augment the functionality and
appearance of the Application(s) without adding primary and substantial
functionality to the Application(s);
[…]
(vi) Licensee shall not use The Qt Company’s or any of its suppliers’
names, logos, or trademarks to market Applications, except that
Licensee may use “Built with Qt” logo to indicate that Application(s)
or Device(s) was developed using the Licensed Software;
[…]
(viii) Licensee shall not grant the Customers a right to (a) make copies of
the Redistributables except when and to the extent required to use the
Applications and/or Devices for their intended purpose, (b) modify the
Redistributables or create derivative works thereof, (c) decompile,
disassemble or otherwise reverse engineer Redistributables, or (d)
redistribute any copy or portion of the Redistributables to any third
party, except as part of the onward sale of the Application or Device
on which the Redistributables are installed;

I don’t believe you’re hiding anything intentionally, nor am I even sure this scary “.QT-ENTERPRISE-LICENCE-AGREEMENT” I found (from a link of your JLL) applies, but if it does, then e.g. (vi) would be good to know.

B.
How does this package compare to other GUI toolkits, e.g. Mousestrap.jl (and/or GTK4 it’s built on)? Does it enable all of QML/Qt6?

GTK3 and GTK4 (and thus GTK4.jl) I understand are very complex (and its docs), but Mousetrap simplifies it the API, and its docs seem excellent as claimed.

GTK4 itself allows for GUI builders, e.g. Glide, but despite that @Clemapfel Mousetrap’s maker decided to not support them, also simplified from many window types GTK4 supports to just one.

@Clemapfel avoided Qt/QML for some claimed good reasons; and for mistaken, or not, reasons: not being as easy to use without paying Qt Company.

Works natively on Wayland (thanks to the fact that we are using Qt 6)

Great I think. Does it still support X? I know people who hate Wayland believe X API is still better. But Wayland seems like the future. If it actually supports both, do you know what it defaults to?

Works natively on Wayland (thanks to the fact that we are using Qt 6)

Great I think. Does it still support X11? I know people who hate Wayland believe X11 API is still better. But Wayland seems like the future. If it actually supports both, do you know what it defaults to?

EDIT: I think it supports both, see ENV var here (the post is there… not “deleted”):

For this to work optimally, the graphics driver must support Wayland. This support is provided through an extension to EGL which is called EXT_platform_wayland.

Note: Qt Wayland also supports compositing on systems where EXT_platform_wayland is not supported, either through XComposite or by copying application content to shared CPU memory. But for optimal performance, we recommend systems with driver support.

X11 has been extended to support features such as composition and direct rendering, but Wayland is designed around this use case from the ground up. It also aims to be small and extensible, in contrast to the complexity that has developed in X11 over time.

  • Regarding the license choice, please see change license to MIT? · Issue #150 · JuliaGraphics/QML.jl · GitHub
  • As you noted both Wayland and X11 are supported, Wayland is activated automatically by loading Qt6Wayland_jll when QML.jl detects it is running on Wayland. No user intervention should be needed. I’m running Wayland with Hyprland on my home machine and haven’t looked back since :slight_smile:
2 Likes

It’s a very widespread misinformation, that Qt is not free to use for businesses.

It is.

The LGPL 3 strictly allows for that. The people who bought Qt are simply interested that businesses buy their licenses, so they word it so, that you may believe it is mandatory.

You can avoid open sourcing your own app, so long as you link dynamically, and release the source code of the changes to Qt itself.

If you read the license, or even the explanation on their homepage, you can clearly see that:

In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library. In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.

2 Likes

As someone who has packaged X11, and who knows about the severe security issues with it, I think Wayland can not come quick enough.

Hate doesn’t bring us anywhere, and its usually spread by people, who go nowhere. :wink:

QML has multiple ways to build UIs graphically. Again, Qt dances around that fact, that you can totally do this open source, but that’s possible.

Please note, that Qt offers two different widget sets: The old Qt-Widgets and Qt-Quick.
Qt Quick uses QML. The UI builders are also twofold, so there is room for confusion.

First, there is the Qt Creator. That is more or less an IDE, that also has the capacity to load plugins for the UI design.

The name for the Qt Widgets ‘UI designer’ plugin is “Qt Designer”.
The name for the Qt Quick ‘UI designer’ plugin is “Qt Design Studio”.

To add up to that confusion, is the Qt Design Studio also available as a standalone application.
As such, it is much more streamlined, and offers a more modern interface.

This is also the version, I recommend.

In order to install it, download the Qt Online Installer.

That’s the easiest way.

The Qt Company is dependent on commercial licenses, so they really take great effort, to discourage you to use the open source products.

Still, they do exist.

2 Likes

Qt is no-cost (for businesses or anyone), well until it isn’t, if you use too many features, if your program isn’t GPLed. “Free” has two meanings and Qt is “free software” aka libre, always.

To quote from your link:

The commercial license is recommended option for non-open source projects.

Why? For their benefit… and when you fund them then, and it may help you indirectly in the future. But it’s “recommended”, i.e. you don’t need to follow that recommendation. Let’s see were that leads:

The primary open-source license is the GNU Lesser General Public License v. 3 (“LGPL”). With the LGPL license option, you can use the essential libraries and some add-on libraries of Qt. This allows for keeping your application source code closed as long as all the requirements of LGPLv3 are met.

You’re restricted to “essential libraries”, and I asked does QMT.jl support full Qt? If it does and you use those extras (I don’t think you will be accident, or even that QMLjl supports at all), then it means some additional libraries that are dual licensed GPL/commercial, and that forces you into making your application GPLed, practically speaking most often no cost, or you pay Qt’s commercial licence.

Either way, your code is at least LGPLed, can be commercial, and you have obligations:

  • Complete corresponding source code of the library used with the application or the device built using LGPL, including all modifications to the library, should be delivered with the application (or alternatively provide a written offer with instructions on how to get the source code). It should be noted that the complete corresponding source code has to be delivered even if the library has not been modified at all.

So if you compile your Julia app, use PackageCompiler.jl, you must distribute more that you get out of it. And even if you just distribute your app as source code, then you’re using JLLs that distribute Qt binaries, and even though those are unmodified, it seems you need to distribute the source for them… or the written offer. It seems you do not get away with posting a link to Qt (source).

  • In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library. In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.

So, I think we are dynamically linking to Qt, but in case we are statically linking, then it means you must provide your application source code. The point of dynamic linking (or one of, from the point of Stallman), if that you can switch out the dynamically linked library. That’s possible if it’s a .so or .dll file you can find and replace, but I’m not sure this concept applies in general for Julia. E.g. users of @Clemapfel’s Mousetrap.jl should get the source code for it (not just for GTK4), or a written offer, and if not dynamically linked, to the full app. The LGPLv3 doesn’t define dynamic, but it refers to the GPL where I found the word.

LGPLv3 has this clause:

The “Minimal Corresponding Source” for a Combined Work means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version.

https://www.gnu.org/licenses/gpl-3.0.en.html

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work’s System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.

The Corresponding Source for a work in source code form is that same work.

You don’t “accidentally” use features. Those, who are non-free, are available by distinct libraries, that you have to buy licenses for. As an example: The Fidget and Photoshop import library for Design Studio, is only available in the enterprise version.

That is the case for any GPL software. The Linux kernel has an even more restrictive license than Qt,

As I have pointed out, is QML the programming language for Qt Quick.
Qt Widgets is not supported. That has nothing to do with the license.
The whole KDE Plasma desktop, plus literally hundreds of KDE and thousands of Qt applications, are fully open source.

Can this licensing discussion be taken to a separate thread, so that the focus can remain on the exciting new release here?

I, for one, am very glad to see this release. QT was my first choice to create GUIs, and QML is such a pleasant way to do it. So I’m glad to see QML.jl revived and active again!

8 Likes

Yes, I’m open to LGPL/Qt/QML licencing discussed elsewhere, or maybe not much more to say. I just can’t split off the discussion.

I would still want this part, from the Qt website, not split off:

  • The user of an application or device created with LGPL library has to be notified of their rights by providing a copy of the LGPL license text to the user and displaying a prominent notice about using the LGPL library – i.e. it is not allowed to hide the fact the LGPL library is used.

MIT hides that fact, that’s why I brought this up, responded to the licence change here. It’s the responsibility of @barche’s QML.jl, not so much his; maybe an ethical obligation to doc LGPL used by dependencies (and that fact), if MIT kept, or at least very helpful to his (possibly ignorant) users.

1 Like

Dear @barche,

Thanks a lot for your great work!

It should also be mentioned that QML.jl is now part of the JuliaGraphics organization, so hopefully there will be more people helping out with the maintenance of the package.

I plan to help with testing, documenting, examples and looking at issues.

Perhaps as first step you can close the following, obsolete issues?

161
151
133
125
103
97
66
51
50
43
36
24
28

Thank you!

2 Likes

I absolutely agree. QML has brought me to programming, and I adore its declarative nature.
Thanks a lot for bringing this on rails again.

We succeed this here.

@barche Thanks a ton, that you made this release available, and that you moved the ownership over to JuliaGraphics, where it’s a bit easier now to manage it. Superb release :tada:

1 Like

A post was split to a new topic: How does licensing work for packages that wrap other-licensed binaries?

Yes, let’s keep the licensing discussion to How does licensing work for packages that wrap other-licensed binaries?.

I tried to split out more posts, but they actually touch on many wide-ranging points (in addition to the licensing of wrapper packages, there’s QT’s dual licensing and technicalities of GPL vs. LGPL itself, etc.) as well as being muddled with QML’s functionality here… and I wasn’t able to see a path towards sensibly re-shuffling more posts in a way that left both threads making sense.

Going forward let’s keep things focused on the package at hand here.

6 Likes

I created a road map: QML Roadmap · JuliaGraphics · Discussion #4 · GitHub

Feel free to comment on it… (and free to pick up tasks…) :sweat_smile:

2 Likes