[lrossi]

I am aware of that environment variable. The problem is that I think almost nobody is using it, so it could come with a risk of introducing more bugs.

By the way, the example shown in the documentation page that you link to seems ridiculous:

  void *slist = g_slist_alloc (); /* void* gives up type-safety */
  g_list_free (slist);            /* corruption: sizeof (GSList) != sizeof (GList) */

This bug should actually be caught during compilation if we store the list in a GSList* typed variable instead of void*. You’d think: who does that?

Except that this is what you actually end up doing when using any kind of nested glib containers. Elements are always void*, so you have to cast them correctly. So for non-trivial applications, it’s very easy to make mistakes, since you lose the type checking support of the compiler.

C is already a tricky language. Removing the type checker makes it even worse.

[baybal2]

You seem to know a lot about Glib. What did you do with it?

I looked to port Gtk to MCU, and then gave up. Too much C trickery, and hard to replace, heavy dependencirs.

For somebody who knew Qt, and Gtk since 2003, it looks like a miracle now how Qt got smaller, and faster than Gtk, and can even run on an MCU, and quite well!

Very big contribution to that was Qt's team willingness to undo the wheel reinvention, and willingness to throw out their hacky attempts to replicate new c++, and standard lib functionality.

The Glib+Gtk world, unlike Qt, still lives in ANSI C, and C99 era, and refuses to concede on reinventing functionality of modern standard libraries, language features, and compilers.

[lrossi]

I worked on some Linux apps in another life. I switched to Qt at some point. It was a breath of fresh air! Qt is very reliable and well documented. One can be very productive with it.

I think a lot of people have a bad opinion about it as they confuse it with KDE. While KDE does use Qt, the two projects are otherwise independent.

I’ve also looked inside the Qt code base a few times. It’s very tidy and quite easy to read. You can tell that their team is very experienced. I used to read their blog as well, they had a lot of good articles.

I really hope that they can continue to survive financially. Selling a mostly open source library is not very profitable.

[ldng]

The problem with Qt is The Company. They have a tendency to cater to their exclusive needs and not bothering much with Linux. A bit like Mozilla. Yet they're claiming to be fully cross-platform. They pushed 6 with regressions.

Qt is undoubtedly interesting but really have steering issues.

[pjmlp]

Here is the thing, GNU/Linux desktop developers aren't those who pays their bills, so they cater to the OS vendors and OEMs that actually pay them.

[ldng]

And I fine with that. But then drop the multi-platform bullet point from the marketing brochure. It becomes a lie at some point.

[baybal2]

> They pushed 6 with regressions.

Gtk pushes every minor version with regressions.

Qt looks quite good in comparison.

[ldng]

Well if you don't count missing modules as regression, sure ...

[the_why_of_y]

The Glib+Gtk world chose to limit itself to a C ABI, which makes it far easier to interop with other languages than C++ as used by Qt.

This is the case both for statically compiled as well as dynamically interpreted language implementations; the latter can use automatically generated bindings via gobject-introspection, which has no equivalent in the Qt world, where all language bindings are hand-crafted at great effort.

https://gi.readthedocs.io/en/latest/

It also means that the implementation behind the ABI can be replaced with a different language such as Rust, as has already been done with librsvg. On the other hand, Qt will forever be stuck with legacy C++ language, which appears designed to be nigh impossible to interop with.

And if you have a requirement to use C++, there is the gtkmm binding too, which doesn't require a separate language extension such as Qt's MOC to use.

https://www.gtk.org/docs/language-bindings/cpp/

[Asooka]

Qt can trivially offer a C ABI if they want. Glib can't be type safe no matter how hard they try. People don't seem to have any trouble making Qt bindings for languages like Go, Python, Java, all of which you could say strongly prefer interop with C. Part of the reason is that Qt is written in a way that avoids use of more exotic features and templates for most things. MOC could be replaced by template magic nowadays, but I don't see any value in doing so - you will just make compilation slower and bindings with other languages harder.

[baybal2]

Well, I mean they could've moved up to more recent standards well within the C world.

As of now, Glib doesn't even utilize much of C99.

[h_anna_h]

> g_list_free (slist); /* corruption: sizeof (GSList) != sizeof (GList) */

Catching this error at runtime would be extremely trivial. Just add a magic number on top of the GSList and GList structs.