1. 27
  1.  

  2. 30

    Over the summer I started dabbling in GTK3. I made the mistake of looking at pretty much every ‘GTK3 tutorial’ on the internet, almost all of them involve Glade. After ending up with something not working 100% of the time, I jumped on IRC, was told:

    • basically exactly what was written about here (don’t use glade)

    • don’t use the ‘official’ GTK ‘tutorial’ docs/blog posts, they’re outdated/not functional

    • only use gnome-builder

    • reference the source code for 3-4 gnome app projects for information on how to use the API (including how to use/structure xml UI portion)

    I hope they do some deep soul searching soon.

    1. 9

      Agreed. The article is the usual “GTK devs broke things and blame other people for it” we saw for years.

      1. 2

        I wonder if the situation is significantly better at the kde side. QT stuff looks a bit more… Product oriented.

        1. 9

          I maintain a 10 year old Qt project and it compiles pretty much like it did when the project started. I think that in those ten years I have replaced a handful of lines because a method was deprecated. In all those cases, the documentation pointed me to the right replacements (the Qt documentation is really good compared to Gtk+). Also, even without replacing those calls to deprecated methods, the program would still compile fine (I guess they are removed in Qt6?).

          A year ago I had to make a nice, presentable UI for some work project that we wrote in Rust. Since the only functional GUI toolkit for Rust is Gtk+ (through the excellent gtk-rs binding), I wrote the first version with Gtk+. Gtk+ felt very archaic. Glade (yes, we shouldn’t use it, but who wants to write XML by hand) was very primitive compared to Qt Designer. Many of the APIs felt primitive and hard to extend (it’s easy to subclass widgets in Gtk an make your own flavors). And many things were not described in the documentation and I found the answers by digging through old mailing list discussions.

          Another issue is that you should probably only use Gtk+ if you target X11 or Wayland. Gtk+ is unbearably slow on e.g. macOS and does not integrate at all.

          At any rate, the whole experience was so miserable that I ended up making a Python binding and used PyQt to write the GUI, which was very pleasant. As a bonus, the application worked well on macOS and Windows as well and look and feel nearly native.

          1. 9

            Another issue is that you should probably only use Gtk+ if you target X11 or Wayland. Gtk+ is unbearably slow on e.g. macOS and does not integrate at all.

            GTK+ also has zero accessibility support on Windows and Mac. So some users would be completely blocked from using your application.

            1. 2

              I am having similar experience with qt, and wondering why developer still working with gtk, a much worse competitor of qt.

              1. 5

                For me it’s GStreamer and C bindings with GObject introspection.

                1. 3

                  Most likely licensing issues.

                  1. 6

                    I thought the gtk/qt license wars were over a long time ago and QT is now GPL + LGPL (with the option to purchase commercial if you don’t want to have to abide by GPL/LGPL).

                    That seems to offer strictly more options than GTK?

                    1. 3

                      See, I was still in the licensing war mindset. I’d missed that Qt has resolved the outstanding questions with regards to their licensing.

                  2. 1

                    in a word, bindings. gtk works with a ton of languages.

                2. 2

                  I can’t say about KDE specifically (KDE Frameworks are a thing and I haven’t used them in… uh, when was KDE 3.3 again?) but yeah, things are way, way better on the Qt side of things. Qt is very thoroughly documented, there are plenty of examples. When something gets deprecated, you usually know well in advance, and you generally have at least one migration path when the deprecation happens (I can’t describe how GTK does that because I inevitably descend into rage and snark, sorry). As with any large (partly) commercial codebase bugs do sometimes get ignored for a long time, especially in the Widgets, but in my experience, the “here’s a bug – this is not a bug” dance is very infrequent.

                  This is mostly a general experience, of course. There are exceptions (things that get deprecated too soon/without adequate replacements/without a proper announcements etc.) but they’re rare.

                  I’ve used both and between 2007 and 2020 (and especially in the GTK 3 age) my attitude towards GTK has slowly gone from “either GTK or Qt is fine, just pick the one you like and maybe the one that matches the DE most of your users prefer” to “I wouldn’t touch this even if you paid me to”.

            2. 21

              The responses to this post are pretty spot on. Asking people to hand-edit XML files to do UI design is stupidly backwards and I can’t even…

              1. 17

                … poster proceeds to edit HTML and CSS in an IDE, watching results in a browser.

                1. 9

                  Yes, this blog post is missing the part where another better tool is recommended.

                  1. 5

                    Yes, we should be drawing mini ASCII art instead:

                    "H:|-[button1(200)]-(>=10)-[button2(200)]-|"
                    
                    1. 3

                      Do Apple developers still use this?

                      1. 2

                        No, that was the first version of auto layout. I remember using this syntax for one year, iOS SDK 6 I think? Tools / SDK releases are annual just like phone hardware, and we’re on SDK 14 now, so it has been a good while. Anyway there was one initial year where Interface Builder, the visual layout tool, made constraints hard to get right, and that year my teams did constraints in code. We came around to IB again when they improved it a year later.

                        The primary ways to define constraints now are either to draw them in Interface Builder or use a new more expressive and type-safe code syntax. If I recall, that was new with SDK 8. I believe all of this was pre-Swift.

                        However the true new hotness is SwiftUI, which is a React-like declarative UI system that tends to operate in flexbox-like stacks and permits specific, dynamic layout in ways other than a system of linear equation constraints, so your don’t then have to debug them for over- or under-definition. SwiftUI cannot yet do everything, so adoption is slow, but that’s the state of the art over in Apple dev world.

                        Suffice to say, VFL is ancient history.

                        1. 2

                          I suspect it’s not very popular these days. VFL dates back to the time before Swift when ObjC would have forced extremely bracket-y APIs. With Swift we get more fluent APIs.

                          Many new projects probably start with SwiftUI, a completely new UI toolkit. It’s still limited, but nice where it works. Most UIKit/AppKit apps use Interface Builder, Xcode’s graphical GUI builder. Of those that prefer UIs in code (I certainly do), many probably use a third party wrapper around auto layout, such as SnapKit:

                          box.snp.makeConstraints { (make) -> Void in
                              make.size.equalTo(50)
                              make.center.equalTo(container)
                          }
                          

                          Or they use Apple’s newer anchor API which is almost as nice:

                          NSLayoutConstraint.activate([
                              box.widthAnchor.constraint(equalToConstant: 50),
                              box.heightAnchor.constraint(equalToConstant: 50),
                              box.centerXAnchor.constraint(equalTo: container.centerXAnchor),
                              box.centerYAnchor.constraint(equalTo: container.centerYAnchor),
                          ])