Actual C compiler for Windows for free

[Karel]

... without any of the gpl problems Qt brings to the table.

What are you talking about? Since when Qt brings gpl problems to the table?

The opensource edition of Qt is LGPL licensed which means you can freely use it in all kind of programs including
closed source and commercial programs without the need for an additional license or to pay a fee.
The only exceptions are: when linking static with the Qt libs and/or when you modify the Qt libs.
In the latter case, it suffice to opensource only the modifications of the Qt libs.

You need a commerical QT License for each Developer, if you want to make a living from your work.

You are wrong.

Again, the opensource edition of Qt is LGPL licensed.
All software that is LGPL licensed can be used to make a living from your work. Period.

[udok]

... without any of the gpl problems Qt brings to the table.

What are you talking about? Since when Qt brings gpl problems to the table?

The opensource edition of Qt is LGPL licensed which means you can freely use it in all kind of programs including
closed source and commercial programs without the need for an additional license or to pay a fee.
The only exceptions are: when linking static with the Qt libs and/or when you modify the Qt libs.
In the latter case, it suffice to opensource only the modifications of the Qt libs.

If you want to make a living from your work, you need a commerical license.
You can only distribute your App, if you have a valid license subscription.

Over 4500$ for each developer and a one year subscription!

https://www.qt.io/pricing

[Karel]

You are NOT obliged to buy a commercial license. The Qt Company just wants to give you that impression.
You can use Qt in commercial closed source applications without the need for a commercial license, as long as you don't link static.
The Qt company is free to ask money for a commercial license.
You are free not to buy the commercial license and to use the opensource edition of Qt in commercial closed source software.
Don't believe their b*llsh*t.

edit:

https://softwareengineering.stackexchange.com/questions/47323/can-i-use-an-lgpl-licenced-library-in-my-commercial-app

https://www.gnu.org/licenses/why-not-lgpl.html

[paf]

About VLAs (and other stuff) a good reference is:
https://gustedt.gitlabpages.inria.fr/modern-c/

And please remember that VLAs are an optional feature in C11. Yu should test if your compiler has it before using it.

[newbrain]

Don't believe their b*llsh*t.

To be honest, there is very little bullshit on the Qt site.

They repeatedly state (in various forms, this is taken from the FAQ, emphasis mine):

The Qt open source licensing is ideal for use cases such as open-source projects with open source distribution, student/academic purposes, hobby projects, internal research projects without external distribution, or other projects where all (L)GPL obligations can be met.

The only point they get (probably unintentionally) slightly wrong is:

Accept Digital Rights Management terms - Accept Digital Rights Management terms, please see the GPL FAQ

On this page.
Specifically LGPLv3 gives an explicit exemption of section 3 of GPL, the one about DRM.

Moreover, there's a nice page which (correctly AFAICS) details the obligations of the various FOSS license (LGPLv3 GPLv2, GPLv3) used:
https://www.qt.io/licensing/open-source-lgpl-obligations

Disclaimer: IANAL, TINLA - consult a specialized lawyer.
But I've worked for many years as an internal FOSS product owner, and as a go-to person (before legal, which is always needed) for FOSS licensing.
BTW, the product was LGPL, and we were both heavily contributing and making money by using it.

EtA: GPL, in its various incarnations especially the v3 ones, is a very complicated license. For this reasons it's widely misunderstood (even by many FOSS supporters). Sometimes the "peace of mind" of getting a commercial license can seem attractive, one gets some features more (as for Qt) and the cost might be reasonable or completely inconsequential depending of the volume of affairs.

[newbrain]

And please remember that VLAs are an optional feature in C11. Yu should test if your compiler has it before using it.

That's one of the reasons MS compiler does not declare C99 compliance, but does (better, and with explicit command line support) with C11/C17.

[SiliconWizard]

Are you sure you want VLA in C?
https://blog.joren.ga/vla-bad

Sorry, but the undefined behaviour in the very first example* immediately segfaulted my interest and I did not go further.

Yeah, most of this blog's rant is just very silly.
Sure stack space is limited - default is usually 2 MBytes on both Windows and Linux (Edit: on Linux, it depends - on my machines, it's 8 Mbytes). Just allocate a very big object on the stack, and it will just spectacularly crash in the same way. No need for VLAs here.

Code: [Select]

int main(void)
{
    double ThisWontEndWell[500000];
    ...
    return 0;
}

Of course when using VLAs, you should always check that the size will be under some predefined bound before declaring the array. That's common sense.

Now I admit I never use VLAs, but I can see in which situations they could come in handy, and even save stack space - it just allows to allocate the minimum amount you need in a given function call instead of allocating a fixed size (which would be the largest you need). And no, dynamic allocation is not the answer to everything here: it's usually a lot less efficient, and for small objects which only live within a given function, it often doesn't make sense.

Like most other C features, it can have its own risks. Use it accordingly. Yes VLAs can be risky in the hands of beginners. Experienced programmers should have no problem using them properly.

As to MS not supporting them, frankly MS compilers have been notorious not to be fully compliant to the C standard, in particular starting with C99. VLAs are not the only thing missing. Shipping a compiler that is not fully compliant to the standard for alleged security reasons is stupid. If that is even the rationale, which I'm not even sure here.

[Karel]

Don't believe their b*llsh*t.

To be honest, there is very little bullshit on the Qt site.

You are right, I exaggerated there. But I still stand with my other points about LGPL'ed libraries & closed source software.

[Karel]

“Open Source Qt” shall mean the non-commercial Qt computer software products, licensed under the terms of the GNU Lesser
General Public License, version 2.1 or later (“LGPL”) or the GNU General Public License, version 2.0 or later (“GPL”). For clarity,
Open Source Qt shall not be provided nor governed under this Agreement.

https://www.qt.io/terms-conditions/

What The Qt company calls "non-commercial", can be used perfectly fine in closed source commercial software as long
as it (the Qt libraries) is licenced under the LGPL license and not statically linked.

Think about this: if LGPL'ed libraries couldn't be used by closed source (commercial) programs, then they couldn't
use, for example, printf() provided by glibc on Linux.

[newbrain]

Think about this: if LGPL'ed libraries couldn't be used by closed source (commercial) programs, then they couldn't
use, for example, printf() provided by glibc on Linux.

You don't need to convince me: my point was only that the site has quite clear indications of the various license regimens, and does not try to hide the FOSS ones.

I'm 100% aware and convinced that LGPL can be dynamically (or in equivalent ways) integrated in proprietary software, see my own words below:

I've worked for many years as an internal FOSS product owner, and as a go-to person (before legal, which is always needed) for FOSS licensing.
BTW, the product was LGPL, and we were both heavily contributing and making money by using it.

Maybe I should have added "...using it in our proprietary SW".

[Nominal Animal]

If you want to make a living from your work, you need a commerical license.
You can only distribute your App, if you have a valid license subscription.

Over 4500$ for each developer and a one year subscription!

https://www.qt.io/pricing

No. This has been discussed before, but heck, why not, let's repeat.

If you use the LGPL-licensed (License mode: LGPL v3) Qt, and dynamically link your project against those unmodified libraries, you do not require a commercial license, and you do not need to pay a cent to anybody, and your own code is yours, free to sell or distribute as you wish.

Here is how you, as a proprietary software vendor, can trivially fulfill the LGPL requirements.  There are other options, but this set is basically bulletproof and exactly what the Qt developers want, so if you ever find yourself targeted, you can simply ask the copyright owners (Qt developers) a statement you're not breaking their copyrights; and complying in the following way is likely to make the copyright owners happy to help.

• Provide the exact sources for the Qt libraries you use, for every version you distribute or have distributed, as freely downloadable files.
• Include the configure configuration you used to build the binaries, and the exact compiler and compiler version used, so that anyone interested can trivially replicate the exact same binaries.  This can be useful for certain infosec reasons as well (if tainted binaries are suspected).  All this incurs zero risk, and costs you almost nothing to provide these, even if not explicitly required by the LGPL.  This is how you garner goodwill among both users and developers, really.
• Use dynamic linking to use the Qt libraries.  This is automatic if you use Python; in C and C++ you just compile normally, not statically, so your binaries will refer to the libraries in separate files.  This is important, because it is the standard accepted way you explicitly show non-derivative-ness when using LGPL'd libraries.  Since this is the standard practice anyway, the cost of this is zero.
• In your user-visible documentation, proudly mention you use LGPL-licensed Qt [version] libraries, and provide a link to where you provide the exact sources (and configuration needed to replicate the binaries).  Qt is a brand, and proudly proclaiming its use is taking advantage of the brand visibility; and you'll make the Qt developers happy too.

To obtain the sources to the Qt libraries, go to the Qt site, and scroll to the bottom of the page.  Near the bottom right corner, under "Community", pick the "Downloads" link. On that page, in the "Downloads for Open Source users" block, click the "Go open source" link.  For the sources, on the following pages that continue to scare you away from open source to the commercial licenses, you'll finally end up at https://code.qt.io/, with build/compile instructions at [url=https://wiki.qt.io/Building_Qt_5_from_Git]https://wiki.qt.io/Building_Qt_5_from_Git[/URL].  These two pages are the ones you need to bookmark, as you'll often return there, and going through the Qt site is a pain.

Or, you can just grab e.g. the entire Qt 5.15 long-term release (latest as of 2021-11-01) via git command-line utilities:
    git clone https://code.qt.io/qt/qt5.git
    cd qt5
    git checkout 5.15
You'll need Perl, Python, and a C++ compiler; see Building_Qt_5_from_Git for details.

The Qt 5.12.11 long-term release binaries (application development Qt libraries and the Qt Creator tool) are available as offline installers (also grab the sources for them on the same page!), if you don't want or cannot compile the binaries you want/need with your own application.

That's it.

Now, although the Qt libraries needed for application development, Qt Creator (including Qt Designer for UI design), and even PySide2 (if you want Python bindings too) are all LGPL-licensed, you do want to verify the license for the modules you need.  In particular, for Qt 5, you can consult doc.qt.io/qt-5/licensing.html and doc.qt.io/qt-5/qtmodules.html: Qt Essentials (QtCore, QtGui, QtWidgets, QtMultimedia, QtMultimediaWidgets, QtNetwork, QtSql, etc.) are all LGPL-licensed, and so are most add-on modules (Qt3D, QtConcurrent, QtBluetooth, QtGamepad, QtHelp, QtImageFormats, QtLocation, QtOpengl, QtPrintSupport, QtRemoteObjects, QtSerialPort, QtSerialBus (CAN, Modbus), QtSpeech, QtSVG, QtUiTools, QtWebChannel, QtWebEngine, QtWebSockets, QtWebView).  Modules listed under "Add-ons available under Commercial Licenses, or GNU General Public License v3", like QtCharts and so on, are NOT LGPL-licensed, so those you cannot include in your proprietary projects.  Similarly, "Value-add modules" like "Qt for Device Creation" and "Qt for MCUs" require a commercial license, and are NOT LGPL-licensed.

Because Python is licensed under the zero-clause BSD license, it is perfectly legal and allowed, even encouraged by the developers, to create a proprietary application that uses the Python interpreter for a permissively licensed UI (granting users permission to modify the UI and pass those changes on to other users), Qt libraries (dynamically linked, used under the LGPL license), and proprietary C and/or C++ libraries (containing the secret application magick).  While it sounds like a mess, in some cases this has the best of all worlds: keeps the nitty-gritty details that users cannot and should not really mess with and makes the application stand apart from competitors completely proprietary, leverages known existing LGPL libraries for the UI functionality, but lets the end users fix any niggling issues with the UI itself with permission (but obviously no guarantees after modifications have been done!) from the vendor.  This kind of complete control over the UI is extremely powerful, and may open up completely new, customized uses, for institutional/company clients, while still keeping all licensing issues clear.
It's not difficult to achieve, neither legally nor technically, if properly designed from the get go, instead of just aggregating something together first and then checking how to make it legally/safely distributable.

[Karel]

You don't need to convince me: my point was only that the site has quite clear indications of the various license regimens, and does not try to hide the FOSS ones.

I'm 100% aware and convinced that LGPL can be dynamically (or in equivalent ways) integrated in proprietary software, ...

It was a reaction to udok who is under the impression that you are obliged to buy a commercial Qt license if you want
to commercially use Qt in closed source programs.
The reason that I want to rectify this, is because this discussion pops up every now and then. I believe this is partly caused
by the way the Qt Company communicates about this matter.
In the past, the open source edition of Qt was GPL licensed, not LGPL. That was a different situation and perhaps
this is contributing to the confusion as well after they changed it to the LGPL.

[udok]

You don't need to convince me: my point was only that the site has quite clear indications of the various license regimens, and does not try to hide the FOSS ones.

I'm 100% aware and convinced that LGPL can be dynamically (or in equivalent ways) integrated in proprietary software, ...

It was a reaction to udok who is under the impression that you are obliged to buy a commercial Qt license if you want
to commercially use Qt in closed source programs.
The reason that I want to rectify this, is because this discussion pops up every now and then. I believe this is partly caused
by the way the Qt Company communicates about this matter.
In the past, the open source edition of Qt was GPL licensed, not LGPL. That was a different situation and perhaps
this is contributing to the confusion as well after they changed it to the LGPL.

OK, i had this impression from the Qt Website.

But why do they then provide commercial licenses, and not cheap ones for 4500$ / Year / Developer.

Maybe it is because any larger project will have a need to modify the Qt sources?

[Karel]

But why do they then provide commercial licenses, and not cheap ones for 4500$ / Year / Developer.

Maybe it is because any larger project will have a need to modify the Qt sources?

The commercial edition of Qt adds the following (in respect to the opensource edition):

- extra goodies/modules not avalaible under an opensource license.

- precompiled libs (at least for windows) so no need to recompile everything after an update

- updates for LTS releases, the opensource edition of a certain major version e.g 5.15.x stopped receiving updates when 6.0.0 was released
  People with a commercial license will still receive updates for 5.15.x

- support: your bugreport will be handled faster if you are a paying customer

[Jeroen3]

... without any of the gpl problems Qt brings to the table.

What are you talking about? Since when Qt brings gpl problems to the table?

See the comments above.

[Karel]

... without any of the gpl problems Qt brings to the table.

What are you talking about? Since when Qt brings gpl problems to the table?

See the comments above.

Do you really consider them problems?

Either you pay for a commercial license or you compile the libraries yourself.
Regarding the missing updates, you can find them in newer major release version.
But even with these "problems", I find Qt, with all her defects, still the best cross-platform graphical  toolkit and C++ framework available.

[Nominal Animal]

If one wants to develop GUI applications in C as opposed to C++, Gtk+ 3 is also LGPL-licensed.  (So are its dependencies GObject (and glib), Cairo, Pango, GDK, and Atk.  The https://docs.gtk.org/ pages lists many of their licenses as GPL, but that is not exactly accurate: many are dual-licensed, and some use the older "GNU Library General Public License" form, which is still LGPL, not GPL.)

A minimal example (with compile instructions for Linux and Mac OS; I don't have Windows, so I don't know the exact ones to use there):

Code: [Select]

// SPDX-License-Identifier: CC0-1.0

/* Compile using for example
 *    gcc -Wall -O2 `pkg-config --cflags gtk+-3.0` example.c `pkg-config --libs gtk+-3.0` -o example
*/

#include <gtk/gtk.h>

static void  main_activate(GtkApplication *app, gpointer data)
{
    GtkWidget *win;

    win = gtk_application_window_new(app);
    gtk_window_set_title(GTK_WINDOW(win), "Example");

    gtk_widget_show_all(win);
}

int main(int argc, char *argv[])
{
    GtkApplication *app = gtk_application_new("com.eevblog.Example", G_APPLICATION_FLAGS_NONE);
    g_signal_connect(G_OBJECT(app), "activate", G_CALLBACK(main_activate), NULL);

    int status = g_application_run(G_APPLICATION(app), argc, argv);
    g_object_unref(G_OBJECT(app));

    return status;
}
User interfaces are inherently event-based, so it is natural to write even C code to conform to the event model, rather than requiring an imperative model (as is common for C programs).  So there is a big paradigm difference in the entire approach, and that can feel jarring.  Don't let yourself be put off by it; in this kind of use, the event-based model –– even if it looks odd/funny/funky for a C programmer! –– actually works really, really well.

Note how uppercase macros (GTK_WINDOW(), G_OBJECT(), G_CALLBACK(), G_APPLICATION()) are used to access the variables in specific "roles".  This is how GObject provides classes and inheritance in C, while still providing type checks.  Don't consider them "casts", as that can lead to seeing them as unnecessary irritant in the coding style; consider them the way GObject provides multiple roles for each type (especially GtkWidget and its "derivatives"), according to the type hierarchy.

One can use Glade to design the UI, saving it as a .glade file (XML format description of the widgets).  These .glade files can then be realized easily using e.g. gtk_builder_new_from_file() (or gtk_builder_new_from_string()), associating callback names with functions using gtk_builder_add_callback_symbol(), and connecting events with the named callbacks with gtk_builder_connect_signals().  One can even access individual objects described in the .glade, using gtk_builder_get_object().  All of this is themeable using CSS, too.

[SiliconWizard]

Note that GTK4 has been out for a while.

GTK is not bad at all. (On Windows, the same compile line will work under MSYS2.)
The UI looks a lot less like "native" UI on MacOS and Windows, which is one of the reasons it's frowned upon a bit on those platforms, but it does work reasonably well.

One of the things that often ticks people off are the non-native common dialogs (such as File Open). But there's a way to have them using GTK.
For instance, you have the 'GtkFileChooserNative'.

[PlainName]

One of the things that often ticks people off are the non-native common dialogs

Hate that. Prevents stuff like Listary and similar from working, so a massive productivity killer. In fact, sometimes I think about running such an app and then think forward to opening some file well down the directory tree and think, "Sod that, can't be arsed".

[Karel]

QFileDialog Class:

By default, a platform-native file dialog will be used if the platform has one.

https://doc.qt.io/qt-5/qfiledialog.html

Apart from the native file chooser dialog, Qt has the best native look and feel when compared with
other cross platform gui toolkits and frameworks.

[Nominal Animal]

Qt has the best native look and feel when compared with other cross platform gui toolkits and frameworks.

No, that would be wxWidgets, because it uses native widgets if one exists, and only implements its own when there is no close-enough native one.  See e.g. screenshots for 3.1.5 (latest as of 2021-11-05) for the differences.

It too has a native file selection dialog; so do Qt, GTK+, and FLTK, too, so nothing surprising.  If an application uses a non-native File (Open/Save) dialog, it's the developers fault, and is easily fixable, in basically all applications, by using the proper dialog widget instead.

[Karel]

Let's agree we don't agree 

https://doc.qt.io/qt-5/gallery.html

[PlainName]

Let's agree we don't agree 

It's nice to have dialogs that follow the native style (except, perhaps, the W10/11 white-on-white borderless annoyance), but looks is just skin deep. The importance of using the actual native dialogs is that the user can replace them with more appropriate ones, or even just inject hints, and every app on the system will use those instead without the programmer needing to modify his product especially. Kind of like the reason for LGPL.

Sorry if you're already aware of that, but you do seem to be banging on about looks. Function matters a lot more.

[Karel]

Sorry if you're already aware of that, but you do seem to be banging on about looks. Function matters a lot more.

Actually, I agree with you. But it seems that a lot of people do care about it (they prefer to use software that have native look & feel).
In other words, you can make (from a functionally point of view) the perfect software, but if users don't like the esthetics, they run away...

[Nominal Animal]

Let's agree we don't agree 

Or let's agree that you're just wrong, because Qt is not native, it just implements its own widgets in a style that looks like the default theme on each OS (possibly with limited OS theme emulation, I'm not sure), whereas wxWidgets are the native widgets.

What you showed is that by default, Qt provides a preferred look-and-feel on different OSes.  That I could agree with, I guess.

Native widgets start to matter a lot when we start using stuff like screen readers and Braille displays and such.  If the widgets are native, and the OS supports those devices, then everything Just Works.  If the widgets are self-implemented, and only emulate a "native look and feel", it means those devices won't work unless the widget toolkit has special support for the devices.  Usually they don't.

wxWidgets uses the native widgets for all widgets that do have native implementation, so although the default wxWidgets "looks" may be plainer/uglier than typical, the widgets are genuine, and therefore all those screen readers and special displays just work.

This can seem like nitpicking or semantics, but "native" is an important concept here.

We could argue whether "native look and feel" implies native implementation (as I believe it does), or whether it allows emulation (which I do not believe it does, because if it did, then the word "native" would be just a synonym of 'expected' or 'typical').