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?
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.
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:
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.
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
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.
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.
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.
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.
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!
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.
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?
@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
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.