4 ms·

> 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 an

> 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". ;)

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". ;)