I mean sure, but a lot of open source software is driven by the idea that developers "scratch their own itch".
It's a bit of a pain that so many patchsets need to be maintained separately for common "scratch my own itch" type features in GTK, instead of the feature just getting buried in a gconf setting somewhere. There are an increasing number of little things in GTK that require you to do things the "gnome way" or maintain separate patch-sets. Any attempt to figure out how we can satisfy both parties gets disregarded pretty quickly.
Obvious examples include thumbnails in the file-picker or type-ahead instead of relying on gnome's tracker or slow file-search.
I guess there's some subtle difference between "hostility" and "refusal to co-operate with other stakeholders" that I'm not getting.
> It's a bit of a pain that so many patchsets need to be maintained separately for common "scratch my own itch" type features in GTK, instead of the feature just getting buried in a gconf setting somewhere.
In this case, the pain is in the right place. Mainline needs to be very careful about signing up to maintain new code, especially if it's used by almost no one.
Thumbnailing is one of those things that's difficult because it's a desktop service. Windows / OS X has one desktop, so there can be a tighter integration between the toolkit and the desktop. My recollection is that thumbnails in GTK+ work fine assuming you have the GNOME thumbnailer running, but lots of people use GTK+ outside of those environments, and it doesn't work there.
This is usually when someone says the word "standards" and expects everyone to go "oh, we haven't thought of that!", but standards take a lot of work, and if there are disagreements in the design and direction of the system, no standard is going to be made. My recollection is that thumbnailing was just one of those things.
Sorry, I think I misspoke. Thumbnails do generate properly and show up in GTK file picker, without needing any kind of hard dependency on gnome or any desktop services. That's not actually a hard problem, it was standardized way back.
This right here has collected most of the patches I'd consider to be important, and the maintenance requirements do not appear to be significant. Of course it is work that doesn't directly benefit the gnome DE.
But it's important to note that GTK is not gnome. It's really important to recognize that as gnome fights harder to become it's own platform, that other platforms do make use of GTK. The gnome-foundation being completely inflexible on the needs of other projects means that at the end of the day it is really hard for other people to collaborate on GTK.
Gnome can do whatever it wants, but the idea that GTK is only supposed to serve the gnome project does seem like a bit of a betrayal. That seems to be a pretty common thought: https://en.wikipedia.org/wiki/GTK#Criticism
It's a bit of a pain that so many patchsets need to be maintained separately for common "scratch my own itch" type features in GTK, instead of the feature just getting buried in a gconf setting somewhere. There are an increasing number of little things in GTK that require you to do things the "gnome way" or maintain separate patch-sets. Any attempt to figure out how we can satisfy both parties gets disregarded pretty quickly.
Obvious examples include thumbnails in the file-picker or type-ahead instead of relying on gnome's tracker or slow file-search.
I guess there's some subtle difference between "hostility" and "refusal to co-operate with other stakeholders" that I'm not getting.