gtk 3.24.0 was tagged last week:
There have been API changes and some things on Windows and Mac broke. Just wondered what anybody thought of the unexpected 
release. Make a vote and explain your reasoning below. 
3.18.x and be done with it. It’s stable and we know it.3.22.x for whatever reason.3.24.x, it promises to be the future.gtk+3?0 voters
The gtk+3 maintenance team is on 3.24.x now, so problems with the quartz backend for Mac and other issues on Windows are likely to be addressed. Those that choose this route and work in a non-Linux OS will have to be patient for the patch versions to roll out.
After using RT for many years, I recently came back to Windows (for personal and academic reasons) and I woudn’t like to see my raw editor crashing “just because it’s the future” and “issues on Windows are likely to be addressed”. Does the current GTK is not good enough for RT? Is current GTK3 holding RT development?
Please make the upgrade to GTK 3.24 after issues are solved, not before. Don’t develop software on hopes, develop software on reliable software. I know there’s a clear emphasis on Linux OS, but there’s Windows and Mac users too, and this is probably where RT can get more and more users because of it’s bigger market.
why no gtk4 in the list?
to answer your poll: Wouldn’t it be easier to learn to handle change efficiently instead of investing so much energy in trying to avoid it?
gtk4 seems like a whole different ecosystem. To handle change efficiently I’d have to start keeping track of multiple copies of entire /opt folders on my mac system. edit: which doesn’t seem like a big deal. As far as entire app projects, I would think the earlier people adopt, the sooner bugs are found?
I would guess gtk 3.24 issues might be solved before the RT 5.5 milestone is released…
Hmm, well, the problem is that GTK3 broke so much stuff. Plus they’ve made it behave in ways that I find 100% objectionable. You might call it “learning to handle change efficiently”. I call it “avoiding really bad design decisions”.
Even now, with GTK 3.22, my installation of geany and bluefish didn’t work so well compared to GTK2 - I thought I’d try using the GTK3 versions, but whenever I tried to open a file all the files were sorted alphabetically regardless of whether it’s really a folder or a file. Sorry, I don’t like folders and files intermixed, and my brief search for how undo this unfortunate change in how files and folders are sorted under GTK3 turned up nothing.
Fortunately with Gentoo I have a flag that I can set, that says “use GTK2 whenever possible”. So I re-enabled that flag.
When QT and KDE switched from 4 to 5, I froze all my QT/KDE apps at version 4 until comments in various forums indicated that version 5 was finally pretty well-behaved. Then I uninstalled all QT/KDE apps, and reinstalled them updating to the QT5 versions all at once I just didn’t feel like suffering through the transition bugs. And now QT5 and KDE apps all work just fine and I’m very grateful to all the people who did the early testing and worked out the bugs.
On the other hand, I have regularly built GIMP and and occasionally built PhotoFlow and RawTherapee from git for years, rebuilding GIMP-2.9 and using it for editing almost every day to help catch bugs since back in 2013. And for years I used first Debian Sid and then OpenSUSE Tumbleweed, dealing with bugs as they came along, doing my part to report bugs and contribute to improving Linux.
That was then and this is now. Personally I have no interest whatsoever in helping the GTK people debug GTK3. I do build and use GIMP 2.99, which is the development version for GIMP 3.0, which will use GTK3 (or maybe GTK4). But unlike with the development version of GIMP-2.10 I use GIMP-2.99 as seldom as possible and only to test changes in the color management code. That GIMP-2.99 GTK3 interface is so painful to look at, so difficult to use, it’s not even funny.
What about this GTK3 bug from 2015? I found a solution, but the solution turned out to have a side-effect that was worse than the bug, and no, I don’t remember why I undid the required code change and went back to dealing with the flash to black:
https://bugzilla.gnome.org/show_bug.cgi?id=748498
https://bugzilla.gnome.org/show_bug.cgi?id=771708
What about those awful disappearing/reappearing animated GTK3 scrollbars, that if you search hard enough you can find a way to disable with GTK3, but that option will be removed from GTK4?
As far as I can tell, the GNOME philosophy for GTK3 and even more so for GTK4 is “users will like or lump it, they shouldn’t have control over the interface”.
GTK devs seem to think that the point of every interface is to entertain the user and also make sure the user doesn’t forget that they just moved the mouse or whatever else they might have just done. Well, this seems to be an up-and-coming approach to interfaces - look at how much Firefox moves around, animates this, animates that - it’s just plain distracting, and increasingly difficult or impossible to disable animation effects.
So no, thank you. I will avoid GTK3 and GTK4 to the extent possible, to the last possible minute. The only reason it’s on my computer at all is because of RawTherapee and for building GIMP-2.99, which is to say, most begrudgingly and I’m tempted to stick all GTK3-requiring programs in a prefix and build them from source just to keep GTK3 off my main system.
I’m contemplating freezing my main workstation computer and just not updating it once GTK3/4 and/or Wayland become unavoidable.
The poll is missing the option to switch all GTK3 software to use either GTK2 or else QT. I’d choose either of these alternatives before I’d choose any of the provided choices in the poll.
I don’t like GTK3 and avoid it where I can. Fortunately, @Carmelo_DrRaw still builds a GTK2 version of PhotoFlow. 
Funny how @Elle mentioned Qt: I used to avoid it too because my experience with it was sour.
I like qt for it’s macdeployqt, that is very handy. It hasn’t always worked completely right, but it’s latest 5.11 version can bundle LHDR with no sweat.
Yes, as much as I like quite a few KDE and QT applications, I’ve always preferred GTK2 applications “as a general rule” (though I’ve never used the KDE OR the GNOME desktops). But as GTK3 gets more and more unavoidable I keep looking for QT replacements for my GTK applications.
I don’t see GIMP switching to QT unless something really drastic happens, and most of our wonderful raw processors currently use GTK.
I’m not what you’d call a huge fan of QT or KDE per se (individual applications to one side). But I don’t like the current alternatives at all 
.
Obstinate wxWidgets user here, I let those guys figure out how to map GTK3 to the stable but oldish wxWidgets world. I moved my wxWidgets-based rawproc from GTK2 to GTK3 with the last version, but it only made my dock window manager look better. Of note is that I’m pretty well shut out of anything but mouse-based UI and 8bit displays so a move is under consideration. Right now, that’d be to QT…
Let us not forget that GTK was originally GIMP Toolkit. 
I sort of wish it still were - that thought has crossed my mined several times of late 
- though that would probably mean a lot of extra work on the part of the GIMP devs.
PhotoFlow is rather peculiar here, as it currently supports both GTK2 and GTK3, with a lot of code that is common to the two versions (probably 99% of the code, if not more). So it is a sort of good benchmark for a GTK2/GTK3 comparison.
What I can say is that the GTK2 version is significantly more responsive than the GTK3 one. My feeling is that the GTK developers have changed something in the way the UI events are processed during idle cycles, and this seems to have a visible negative impact on multi-threaded applications like PhF. I do not have a real proof of what I am saying, but the fact that the same code results in a less “fluid” experience with GTK3 is a fact.
For those who do not know it, GTK is not a multi-threaded UI toolkit. This means that any UI function call issued from a thread different than the main one (for example a request to refresh the image preview) have to be registered as idle callbacks, and are processed as soon as the main UI thread becomes idle.
On the other hand, AFAIK Qt is multi-threaded, and such complicated gymnastic is not needed. That’s another aspect that is making me consider to move the PhF UI to Qt.
The culture of the two projects is different too: The Biggest Problem With GTK & What Qt Does Good - Phoronix
I wanted to mention something to that effect, but I didn’t have anything to go on other than impressions from various comments made by the Krita developers over the years - thanks! for the link to the phoronix article.
+1.
Had i known all this back then (or had some way to experiment with nowadays (2.4.x) darktable),
i would not have ported darktable to gtk3 back in the day…
It might turn out that back-porting it to GTK2 is not that difficult… I would seriously consider this if you somehow observe the same as I was describing.
But GTK2 is dead!