I have been a hobbyist programmer for four decades.

I have used GTK for the past 15 years. I don't use GNOME. The real issue is that the GTK developers have been making it hard/impossible for applications to do things in ways that would appear foreign on GNOME. That has not impacted my programs on GTK 3. GTK 4 may be a different story.
Ed

Not to sound like I myself am trying to sell something (I'm not), but right now I'm working on a fork of GTK+ 2 which aims to be as usable as GTK+ 2, yet emulates (hopefully) all later versions of GTK. My project is known as STLWRT, so called because it's for those of us who like GTK the way it was (us stalwarts), but the name has been capitalized (like GTK) and shrunk down to 6 characters (double the number of characters in the name "GTK" to show that it emulates at least two versions of GTK). It accepts GTK+ 2 themes natively. It preserves the old GTK+ 2 user interface. It only implements the features of GTK+ 3 which are needed by real applications. It implements the compatibility between versions of GTK in such a way as to nearly eliminate the problem of code duplication. I actively maintain it and it is almost ready for release.

What do you think of that?

That's cool, but GTK 2 is now irrelevant to me, and I don't expect STLWRT will outdo GTK 3 in features and performance (but correct me if I am wrong!)

You need to look to the future and make your library more attractive to application developers than the upcoming GTK 4. That is a tall order and likely impossible with fewer resources than Red Hat.
Ed

The alternatives I've seen don't default to a theme that produces skinny or invisible scrollbars, favors scroll-to-click, and omits all steppers. To me such a default is an offering of less.

Unfortunately, the GTK and GNOME developers have been conducting a science experiment in GUI design. They are making dubious design decisions to find out what does not work.

GTK 3 can produce beautiful, conventional scrollbars that are part of beautiful, conventional GUIs. It just does not do that with the default settings and theme.
Ed

Isn't that essentially what I said in posts #10 and #13?

I don't really understand your stance here.
Either you aren't getting my point, or I am not getting your point, or both, or you're being diplomatic, avoiding any sort of stance - but why would you be posting in the first place then?

BTW, what about M Uplawski?

I think we are saying the same thing: GTK 3 is a state-of-the-art GUI toolkit which is being hampered by the developers' inability to see beyond GNOME.
Ed

2 members found this post helpful.

EdGr, I don't think you get the point about STLWRT. You don't write an application to take advantage of STLWRT (unless you really want to); if you like the old fashioned user interface afforded by GTK+ 2 but you have applications which use GTK+ 3, you install STLWRT instead of either version of GTK. STLWRT emulates whatever version of GTK your applications want to run with; there is no reason to recompile an application to use STLWRT. The use of STLWRT over GTK should be up to the user of the application, not the application developer.

STLWRT has another neat feature: Normally if you have applications installed, some of which use GTK+ 2 (like stable versions of the GIMP) and some of which use GTK+ 3 (like Inkscape), you'd have to have both versions of the GTK library installed at the same time. And most of that code in GTK+ 3 is actually quite similar to the GTK+ 2 code. (I know this because I've looked extensively inside both libraries.) On my system right here, just the main GTK+ 2 library takes up 5 MB and the main GTK+ 3 library takes up 9 MB. OK, these days that might be a drop in the bucket, except this adds up: Back in 2016, the GTK project discussed the prospect of releasing each new major version of GTK at the same rate they had been releasing new minor versions of GTK, so maybe every 9 months. They also said that each major version of GTK (GTK 4, 5, etc.) would be maintained "for eternity" and applications could target one version of the library forever instead of following a moving target. I'll admit nobody's said anything about such a schedule recently, but do you see the problem now? Sure, 14 MB is a drop in the bucket; when you add in GTK 4 for several GNOME applications (11 MB), GTK 5 for this and GTK 6 for that, you have a lot of duplicated code. I don't care about Moore's law; many of us who like the traditional interfaces also have old computer systems (like myself -- I'm typing this on a Pentium III). When you have to have 36 versions of GTK installed to run all your applications, are you still going to be in favor of the GTK method? Maybe. But I'm not.

With STLWRT, sure, every release of GTK it targets might increase the size of STLWRT by a few dozen or even hundred K, but you don't have the same level of code duplication with STLWRT that you do in GTK. Plus you get a nice old interface compatible with your old themes, and I'm even cleaning STLWRT up so that it runs faster than GTK+ 2. (GTK+ 2 actually had quite a bit -- no pun intended -- of extraneous code.) Sure, I don't expect everyone will like it, but I'm still working on it and have gotten a lot of support from other segments of the GNU / Linux community.

It is good that you are designing STLWRT to be API-compatible with GTK since I wouldn't expect many application developers to target STLWRT over GTK.

However, for drop-in-replacement to work, STLWRT needs to implement exactly the APIs of GTK 2, 3, 4, etc. That is a very ambitious goal given the incompatible API changes.

Moreover, application programs still need to have icons in menus and buttons to look like the old user interface.

I am glad to hear that you are receiving interest from the GNU/Linux community. I am not your target customer since I have already migrated my hobby programs to GTK 3. My experience has been that GTK 3 does not give up anything in the look-and-feel department once one rewrites the theme.
Ed

The only way to determine if you are going to be comfortable with a particular desktop is for you to try it. Mate, LXDE, and XFCE all seem to perform similarly and quite adequately for my purposes on my 12-year old netbooks (Atom N270, 1GB RAM), I just happen to prefer the look and feel of Mate.

The pastures aren't any greener over here. Unless you've got specific features you're looking for that you don't have, there's probably no reason to switch.

Ah, we can agree on that!

For instance the XFCE DE has only recently been ported to GTK 3 and that didn't seem to have been too easy:
So the DE itself didn't change that much (4.12 -> 4.14), the work was porting it over.

Yes, all app developers who were using GTK 2 realized that they must move to GTK 3 in order to remain relevant. This includes apps that are not tied to any desktop environment.
Ed

No worries, EdGr. I actually have all that you said under control. And your GTK+ 3 application(s) should work under STLWRT, too. If they don't, bug report it. :-)

From what I read in this thread, I have to either content with Gtk and be happy, or alternatively, content with Gtk and be unhappy.

Now I re-compile one of my old applications which works out of the box when started from the IDE, using the installed Qt-libraries, then fails to run outside the IDE, with only one version of Qt-libraries installed, as there is an unidentified symbol in Qt5. Which is somewhat contradictory.

But it leads to my conclusion, for now: This is (again), all too complicated for me. I do no longer use Gtk for my GUI-applications in Ruby as the Ruby-bindings to Gtk are ill-documented if documented at all. I have never succeeded to work with Ruby/Qt and do not feel like trying again; although the last attempt had been around eight or nine years ago.

Good software, to me, is now something like slrn, mutt, w3m and desktop-environments commence to feel like a nuisance. Maybe I can get away with using an empty OpenBox and not ever asking again...