Linked by Thom Holwerda on Thu 8th Nov 2012 20:54 UTC, submitted by Elv13
Gnome "Theme development is a tedious and difficult task, and for the GTK devs to be so careless in breaking their API at every turn disrespects the many hours people put into making themes for it. [...] I was given to believe that this breakage stems from a Microsoft-like climate of preventing users from customizing their systems, and deliberately breaking the work of others so that your 'brand' is the best. Anytime I hear the word 'brand' being used in Linux, I know something valuable is being poisoned." I find the tone of this one a bit too harsh and overly negative at times, but his point still stands.
Permalink for comment 541571
To read all comments associated with this story, please click here.
Member since:

No, because they inherited Apple NIH sindrom and wont use something because it is someone else idea (until they copy it, then it's theirs). So they did their own language and are working on their own toolchain too. As for copying OSX, once they removed everything, they will have a very nice base to start with.

Enough trolling, I don't think the way GTK is done is future proof or developer friendly. I once was working on a GTK application and had a bug. I had read the doc and everything I could find. The function was still not doing what it was documented to do. So I went on IRC. They were really polite and helped me solve my problem quickly. When I asked how I was supposed to know that the function was not doing what it was documented to do and asked about updating the doc. The devs acknowledged that there was a fair amount of what they call "assumed knowledge". Those facts float on top of the API doc and they confirmed that it does not really represent the state of GTK anymore and that it have to be fixed eventually. I understand they had a major release (3.0) and wanted to clean things up. The problem is, the API un-freeze has not ended ever since, even if it is officially in place.

I have lived through Qt3, Qt4 and Qt5 transitions, I am totally find whit API breakage. I also work on AwesomeWM and no API freeze is one of our core value, even if it drive power users crazy, but we made it clear. API are not frozen until they are perfect and there is no such thing as perfection. The problem with GTK is that dev have to deal with this fog. They can't really see where things are heading and until this have either settled or documentation/migration policies are well defined, their product is in danger.

I use many GTK apps, many complex ones, so I really fear where things are heading, aka: nowhere. Application can not survive unless what they are based upon survive too. It is how free software work, we built upon other people work and rely on this trust that if they provided a public API, we can rely on it until the lib****.so.X.*.* change (X). If some low level projects drop this very fundamental aspect, everything crumble. Forking GTK is not an option as many here think for two reason. The first one is that Gnome would have to fork GTK, not the opposite. As everything else rely on the old (theoretically stable) namespaces and when it come to that, there can be only one. The second is manpower. I don't think C based GTK is competitive (C is not a good GUI language, it wont ever be, C is the best, but only for use cases where it actually is), but removing all the paid for development will make things far worst.

So where are we. We have a team of vision driven developers with a dilemma. Support third party or focus on getting where they want to be. I am fine with vision, I did many project just because I could and looking back I am totally fine with the fact there was no market. But when it impact other peoples work and ideals, is that really acceptable behavior? I don't think so. There is no solution. The GNOME can't be forced to care about something they don't. Even if many of them are paid, they have their own agenda, it's still open source. Third party devs can't switch either, it is too late. It is "go with them or go from scratch" senario. Very few are crazy enough to believe in rewrite unless their own codebase have crossed maintainability infection point. So many issues, so little solutions...

Reply Parent Score: 10