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.

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”.

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.

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),
])