The default GUI library for modules is Qt, used by the great majority of extensions.
I have few questions about GUi libraries:
Are other GUI libraries supported by Slicer 3D? It is possible to use Tkinter but that’s because, I think, it is natively included into Python. Are there examples of existing extensions using another GUI lib than Qt ?
In the development of a Python-scripted module: Is it possible to attach non-Qt windows to Slicer program as it is possible for the windows “SlicerApp real” ? Or maybe it is possible to include non-Qt buttons direclty into the “SlicerApp real” windows ?
Slicer is under a BSD-style license, which authorizes commercial use, but most of the GUIs are made with Qt, which is not commercial-use free. Isn’t there a conflict here ?
You can bring in additional GUI toolkits, but Qt is by far the best (most comprehensive, nicest-looking) free, open-source, multi-platform GUI toolkit. Why would you even consider using TkInter when Qt is already available?
Is it possible to attach non-Qt windows to Slicer program as it is possible for the windows “SlicerApp real”
Usage of Slicer application and GUI classes are optional. MRML core libraries, module logics, CLI modules, etc. do not depend on Qt and can be used independently from the Slicer application. Some features, such as Subject Hierarchy and Segment Editor uses Qt classes as base classes for their plugins, so those will not work without Qt, but most everything else should.
Slicer is under a BSD-style license, which authorizes commercial use, but most of the GUIs are made with Qt, which is not commercial-use free. Isn’t there a conflict here ?
Qt comes with LGPL license, which is free to use, even for commercial purposes. The only practical limitation is that you cannot link Qt to your application as a static library (it must be used as a dynamically-loaded library).
Thank you for your answer.
Actually, yes, if it is possible to use Slicer for commercial purposes with Qt linked as dynamically-loaded lib, the rest of my question makes no sense. For sure Qt is easier to use.
So if I understand well, a home-made Slicelet using Qt as GUI lib can be sold under LGPL license and th only limitation is that Qt needs to be dynamically-loaded. Since Qt can be quite expensive, I didn’t know it was possible. What are the disadvantages in this case ?
I am not an expert but I think it is then not possible to only have 1 .exe file as a final product. Maybe there are some dependances with Qt updates ?
There are no practically relevant disadvantages of using Qt with LGPL license. Qt website tries to convince people to buy commercial license and support, which makes sense for them (and useful for the Qt user community if some people pay for Qt development), but paying is not necessary.
Indeed, here are just few examples of commercial applications made possible by the underlying awesome collaborative work of the 3D Slicer community and beyond:
Technically your application wouldn’t be sold under a LGPL license, it would have its own license and would include a list of open-source libraries associated with it and acknowledge with one of them based on their corresponding license.
Distributing as single executable could be easier and ensure a faster startup time. That said:
I also suggest to run some benchmark to clearly understand what is the bottleneck. Building a cross-platform and static application also comes with its own challenges.
As indicated by the LGPL license, user of your application should be able to provide its own Qt libraries. Unless you provide the source code of your application, this is possible only with dynamic libraries.
Also of course you can make a single .exe that is an installer, like Slicer’s, that is what many windows users will expect. This can include a launcher like Slicer’s to handle the shared libraries as required by the LGPL and also isolates you from any other Qt libraries that might be installed by other apps.
(1) If you statically link against an LGPL’d library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
The only place one might practically need this is embedded/resource-constrained contexts. In the context of Slicer, as Andras said, there’s no downside to dynamic linking (excluding webengine, which is basically Chromium, Qt libraries are “only” ~30 MB, a fraction of the total, and load faster than most of the others).
Thank you all for this complete answer. It gives me (and maybe other users) a better overview of Qt use with 3D Slicer.
Indeed, it seems easier to use Qt under the LGPL license for a commercial use of 3D Slicer, with the few constraints described above. This is good to know for any preparatory work for applications running with Slicer.