I hear QtCreator mentioned on Hacker News quite frequently. A couple of questions, if you don't mind.

1) How well does it work if you are trying to stick to C and not go the C++ route?

2) They are GPL licensed, so not very permissive, or quite expensive for a commercial license. Is there a significant difference in feature set between the open source & commercial versions for someone that just wants to take it for a spin?

> How well does it work if you are trying to stick to C and not go the C++ route?

The IDE works fine, but you're missing on a lot :p. You can use raw makefiles or, better, CMake with it; the integration with cmake's server mode in the latest version is top notch.

> They are GPL licensed, so not very permissive, or quite expensive for a commercial license. Is there a significant difference in feature set between the open source & commercial versions for someone that just wants to take it for a spin?

First, there are two things: Qt and QtCreator. Qt is a C++ library (and also has its own DSL, QML which is a godsend to make modern UIs) and QtCreator is an IDE. While it has a lot of Qt-specific features (eg UI designer, some Qt-specific autocompletions, Qt examples on the front page), it can just be used as a general-purpose IDE for C, C++, Python, and Nim. As such, its license does not matter for you as a developer, unless you want to ship a product with the IDE (for instance Sailfish OS and Ubuntu used a customized QtCreator as the IDE for their respective SDK).

Then, Qt is as you saw, under multiple licenses: commercial, gpl, and lgpl.

* all the libraries are under GPL.

* most modules are additionnally under LGPL.

* two tools are only under the commercial license: QML compiler (but it has been superceded by another approach that was open-sourced) and pre-made images for some embedded boards (Boot2Qt, basically useful for embedded software that runs fullscreen just on top of the linux kernel with no GUI environment, generally on the raw framebuffers or drivers provided by the board vendor).

The things that are under GPL but not LGPL are here: http://doc.qt.io/qt-5/qtmodules.html#gpl-licensed-addons (three modules: virtual keyboard, charts and data visualization). Everything else on the page (ie more than enough for "taking it for a spin") can be used from proprietary apps (you have to make a readme at some point that says that you use Qt, like any other open source libs.) . The simplest is to just use the Qt shared libs, but you can also link them statically:

https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...

>QML which is a godsend to make modern UIs

What advantages does QML provide over using "just the Qt library from C++"? Faster development? I've used an earlier version of Qt (3 or 4) a bit, but never tried QML.

If you are familiar with modern web development, think of Vue.js or React's reactive bindings but as part of the language syntax. See https://qmlbook.github.io/en/ch04/index.html#qml-syntax

e.g. when in "C++ Qt" you'd do :

    connect(m_button, SIGNAL(clicked()), m_object, SLOT(on_clicked()));

or more recently

    connect(m_button, &QPushButton::clicked, m_object, &MyObj::on_clicked);

or even

    connect(m_button, &QPushButton::clicked, this, [=] { /* do stuff */ });

QML would be :

    Button {
      onClicked: /* do stuff * /
    }

Even better is stuff like

    connect(m_slider, &QSlider::valueChanged, 
            m_object, [=] (int val) { m_item->setWidth(3 * val) });
    m_object->setWidth(3 * m_item->value());

which becomes

    Slider {
      id: slider
    }

    Item {
      width: 3 * slider.value
    }

It has a slightly stronger type system than JS; not as strong as TypeScript though. The idea is that when you really need strong typing you do it in C++ and expose your objects to QML (which is a one-liner: every object part of the Qt meta-type system can be used from the QML's side and have its signals and slots called there).

Of course, the big drawback is the performance loss that you get from going from optimizable C++ to Qt's modified V8 engine. However, if you had a graphics-heavy C++ Qt app that relied on QGraphicsScene / QGraphicsView it could be faster in QML since there it's all OpenGL / D3D12 (and hopefully Vulkan) + a modern scene graph, instead of CPU rendering. So like always, benchmark benchmark benchmark :)

Yes, the QML code does seem a lot simpler/shorter. Thanks.

About your second question: as far as I know, you can use the LGPL Qt in commercial projects, freely, as long as you don't statically link the libs.

https://stackoverflow.com/questions/11994053/can-i-use-qt-lg...