Backing helps but that's not the root cause of the project's problems.
The project has /always/ been unfriendly and abrasive. There's a reason why there aren't many contributors--the core team drove most of them away. I was a contributor in the early 2000s as a maintainer of the Print plugin (now gutenprint). I distanced myself from contributing because it was so painful and unpleasant. Same for GTK+. I went and worked on other stuff.
The other reason is technical. Why is the transition taking so long? Because the codebase is written in GObject-based C, and writing and refactoring this stuff is a nightmare. This also puts of a lot of potential contributors, and for good reason. Were it written in C++ or something else more amenable to ongoing maintenance and refactoring, it would have been possible to get this done much more quickly, and it would also have a vastly lower barrier to entry for potential contributors.
Moving to Qt is definitely possible; I've done it for other GTK+ projects. It can even be done incrementally; you could move the whole lot to use GTKmm widget by widget, and then once it's all C++ you can start the move to another toolkit. I'm not saying this because of any sort of Qt vs GTK+ zealotry, but rather because GObject-based C is inappropriate for sizeable codebases; the ability to maintain and refactor and contribute to a codebase matters, and this impedes all of them. Looking at the glacial progress of GIMP and other big GTK+ applications, as well as the bugs it causes, demonstrates this repeatedly. Plenty of other projects made the move and didn't look back, because once done it's vastly more productive to work with a C++ codebase, and with a significant increase in code quality. It's not 1997 any more.
Comments
Backing helps but that's not the root cause of the project's problems.
The project has /always/ been unfriendly and abrasive. There's a reason why there aren't many contributors--the core team drove most of them away. I was a contributor in the early 2000s as a maintainer of the Print plugin (now gutenprint). I distanced myself from contributing because it was so painful and unpleasant. Same for GTK+. I went and worked on other stuff.
The other reason is technical. Why is the transition taking so long? Because the codebase is written in GObject-based C, and writing and refactoring this stuff is a nightmare. This also puts of a lot of potential contributors, and for good reason. Were it written in C++ or something else more amenable to ongoing maintenance and refactoring, it would have been possible to get this done much more quickly, and it would also have a vastly lower barrier to entry for potential contributors.
Moving to Qt is definitely possible; I've done it for other GTK+ projects. It can even be done incrementally; you could move the whole lot to use GTKmm widget by widget, and then once it's all C++ you can start the move to another toolkit. I'm not saying this because of any sort of Qt vs GTK+ zealotry, but rather because GObject-based C is inappropriate for sizeable codebases; the ability to maintain and refactor and contribute to a codebase matters, and this impedes all of them. Looking at the glacial progress of GIMP and other big GTK+ applications, as well as the bugs it causes, demonstrates this repeatedly. Plenty of other projects made the move and didn't look back, because once done it's vastly more productive to work with a C++ codebase, and with a significant increase in code quality. It's not 1997 any more.