6 ms·

Qt doesn't even compete with GTK+, it's in an entirely separate class which GTK+ will never reach. It's an entire application development framework of over a d

by rleigh 6y ago

Qt doesn't even compete with GTK+, it's in an entirely separate class which GTK+ will never reach. It's an entire application development framework of over a dozen libraries, only a few of which are related to GUI functionality. And for the libraries where there is overlap e.g. QtCore and QtWidgets, the Qt design and functionality is again such a step up that it's not even worth comparing. GTK+ is a simple and limited X11 toolkit. It can be visually attractive. But it's not something you would chose rationally based upon features, code quality, code maintainability or having a good developer ecosystem and support. Because it would come in last place on every metric, unfortunately. There are very good reasons people don't use GTK+ for commercial projects. Or even open source projects, unless they haven't learned the hard way yet. Fundamentally: its developers don't prioritise the needs of the very application developers who should be their primary customers. (I used to develop open source and commercial GTK+ applications. What a huge waste of time and effort that was. Utterly soul destroying how many unfixable bugs I had to find and work around.)

marktangotango 6y ago
> It's an entire application development framework of over a dozen libraries, only a few of which are related to GUI functionality. Do you not consider GLib and associated libraries to also fulfill this application development framework role?
- rleigh 6y ago
  Good grief, no! It's not remotely comparable to the array of Qt libraries. Can it handle XML parsing, XSLT transforms, SVG rendering, database access, OpenGL scenegraphs, gamepad input, networking, chart rendering. No. It doesn't even do one of them, and that's not even the full list. GLib is a set of basic C functions for missing standard library functionality which range from acceptable to awful. An "application development framework" it is not. It's a set of simple helper functions and some primitive containers with so-so performance and very little safety. Use the C++ standard library and avoid 99% of it with containers that work properly and classes that aren't fragile because you're still pretending that C can do object orientation and object lifetime management sanely. It can't. Constructing vtables by hand with GObject might be clever to prove a point, but it's no way to write a robust application that the compiler can actually type check and that static analysis can find problems with.
  - cycloptic 6y ago
    >XML parsing, XSLT transforms, SVG rendering, database access, OpenGL scenegraphs, networking Off the top of my head there is libxml2, libxslt, librsvg, libgda, libclutter (and now GSK with GTK 4). Networking is included in the gio part of glib. Unfortunately there are no good gtk/gobject-style libraries for generic gamepad input or chart rendering as far as I'm aware.
    - rleigh 6y ago
      > Off the top of my head there is libxml2, libxslt, librsvg, libgda, libclutter None of which have anything to do with GTK+ as an application development framework. They are independent projects.
      - cycloptic 6y ago
        These are the libraries that most GTK applications are using for those purposes. You can bikeshed about whether they call themselves an application development framework or not but Qt is also split up into separate projects in separate git repositories like this.
        rleigh 6y ago
        The Qt libraries are released together as an integrated whole, all using common functionality in QtCore and being designed to work together. The libraries you mentioned are a random collection of unrelated open-source libraries. There is no comparison. It's not "bikeshedding" to point out a completely baseless argument.
        cycloptic 6y ago
        As far as I can tell, those projects I mentioned are all either maintained by GNOME developers under the GNOME umbrella, used in a large number of GTK apps, or they use glib/gobject and make extensive use of the same design patterns as GTK. It's confusing to me how you're trying to say they aren't designed to work together. The situation is the same as Qt, the only difference there is that it's centered around their C++ QObject design patterns. If the argument is that the Qt libraries are all developed together by paid Qt Company developers then sure, that's true, the libraries I mentioned aren't like that where one company is working on them. But that's different than saying they're designed to work together.
- justinclift 6y ago
  If "cross platform" is one of the requirements, then Hell No. Ditto for "in depth documentation". ;)

by rleigh 6y ago

marktangotango 6y ago

> It's an entire application development framework of over a dozen libraries, only a few of which are related to GUI functionality. Do you not consider GLib and associated libraries to also fulfill this application development framework role?

rleigh 6y ago
Good grief, no! It's not remotely comparable to the array of Qt libraries. Can it handle XML parsing, XSLT transforms, SVG rendering, database access, OpenGL scenegraphs, gamepad input, networking, chart rendering. No. It doesn't even do one of them, and that's not even the full list. GLib is a set of basic C functions for missing standard library functionality which range from acceptable to awful. An "application development framework" it is not. It's a set of simple helper functions and some primitive containers with so-so performance and very little safety. Use the C++ standard library and avoid 99% of it with containers that work properly and classes that aren't fragile because you're still pretending that C can do object orientation and object lifetime management sanely. It can't. Constructing vtables by hand with GObject might be clever to prove a point, but it's no way to write a robust application that the compiler can actually type check and that static analysis can find problems with.
- cycloptic 6y ago
  >XML parsing, XSLT transforms, SVG rendering, database access, OpenGL scenegraphs, networking Off the top of my head there is libxml2, libxslt, librsvg, libgda, libclutter (and now GSK with GTK 4). Networking is included in the gio part of glib. Unfortunately there are no good gtk/gobject-style libraries for generic gamepad input or chart rendering as far as I'm aware.
  - rleigh 6y ago
    > Off the top of my head there is libxml2, libxslt, librsvg, libgda, libclutter None of which have anything to do with GTK+ as an application development framework. They are independent projects.
    - cycloptic 6y ago
      These are the libraries that most GTK applications are using for those purposes. You can bikeshed about whether they call themselves an application development framework or not but Qt is also split up into separate projects in separate git repositories like this.
      - rleigh 6y ago
        The Qt libraries are released together as an integrated whole, all using common functionality in QtCore and being designed to work together. The libraries you mentioned are a random collection of unrelated open-source libraries. There is no comparison. It's not "bikeshedding" to point out a completely baseless argument.
        cycloptic 6y ago
        As far as I can tell, those projects I mentioned are all either maintained by GNOME developers under the GNOME umbrella, used in a large number of GTK apps, or they use glib/gobject and make extensive use of the same design patterns as GTK. It's confusing to me how you're trying to say they aren't designed to work together. The situation is the same as Qt, the only difference there is that it's centered around their C++ QObject design patterns. If the argument is that the Qt libraries are all developed together by paid Qt Company developers then sure, that's true, the libraries I mentioned aren't like that where one company is working on them. But that's different than saying they're designed to work together.
justinclift 6y ago
If "cross platform" is one of the requirements, then Hell No. Ditto for "in depth documentation". ;)