That’s your prerogative………..

“because “I like my toolkit more than yours” is not really a productive line given the subject.”

That’s not what was argued at all. You’ve been given an itemised list of what is currently wrong and what could be improved, and when you look at trying to compete against proprietary alternatives and convincing developers, and indirectly users, to use your software, some of them are *huge* problems that make any licensing and control issues pale into daft insignificance.

“If you want to debate the merits of why we need the LGPL then fine just leave the fanboying at home.”

It’s not fanboying, and I’ve itemised why worrying about the LGPL, everybody developing for ‘free’ and control have become insignificant problems when trying to keep up with the competition.

I’m be quite surprised if you weren’t upset a bit over that though.

Using the LGPL assumes that the software project is self-sustainable enough and has enough code going into it that ensures that it can keep up with the competition and the features demanded of it by developers and users indirectly. It also assumes that there is enough of an incentive for various people to contribute to it significantly to achieve that goal. Developing tools for developers to create applications for end users is probably one of the hardest things in software.

Unfortunately, GTK and Gnome’s other development tools just don’t have that and aren’t keeping up.

I’m just going to leave it at your assessment of GTK+ (and tool kits in general) is wrong in many ways but not worth arguing because “I like my toolkit more than yours” is not really a productive line given the subject. If you want to debate the merits of why we need the LGPL then fine just leave the fanboying at home.

That’s a loaded thing to say. They did look to the future, and they saw resolution independent devices and competitors doing more visually with the devices available to them. If rethinking the platform of the future consists of banging away on blogs back and forth with nothing being written, I don’t really want to hear about it.

“If we lost control we might not be able to move in the directions we would like to go. So in my opinion focusing on features would be the wrong reasons for choosing the switch.”

That, as Yoda might say, is why you fail. Features and functionality are why people use a particular desktop and a set of applications in the first place. It’s *the* reason to exist. If you’re sacrificing that central tenet for an idea of control then you’re never going to get anywhere.

Control is also a fallacy as well. Control is what has held GTK back. Currently, GTK development is controlled by a group of companies, newer ones such as Imendio, but especially Red Hat. Imendio is currently focusing on their own specific niche with no real care for Gnome at all, and Red Hat doesn’t want to put in the resources needed to update GTK because they see absolutely no return on investment in it – quite sensibly.

The question then becomes (deep breath), how do you create a return on investment to make the toolkit viable to put in the features and functionality needed to create the kind of desktop that you want and that people demand to get it to compete on a level with the proprietary alternatives you want to attract people off? You take all that into account and you come to a decision that the KDE developers made twelve years ago.

Not for the companies that matter – the ISVs currently using Qt and paying for what they get out of it. Functionality and features are what primarily matter.

“The LGPL has allowed us to work with a lot of companies who have contributed back to the base platform.”

Unfortunately, they haven’t contributed code and functionality enough relative to other toolkits, and they certainly haven’t contributed what Gnome as a desktop needs from GTK.

“This is so not true I don’t know where to begin.”

It is true. It’s why you have such unbelievable things going on such as libsexy and libegg, and why application developers often copy and paste code into their own applications and then amend it to add the features that GTK currently lacks. That is just unadulterated………horror.

Nice comment, thanks. I don’t think anyone is going to take a contract out on you based on your opinions

Sure, if resource usage is not an issue I prefer Python. But Qt/C++ are also a pleasure to program with *and* you can (can!) get good performance, too.

That being said, I have a lot of respect for C coders and low-level work. However, for some things it’s maybe just not the right fit.
The Gnome hackers could likely get more things done with Qt if they, say, don’t accidentally turn into zombies.

Full community control[*] and licenses -are- an issue and I admit that. Other people have talked about this in a more competent way.
[*] Actually, Trolltech will sometimes do a little something only for KDE. Not the same thing as Real Powah(TM) though.

Forget the red herring about bindings.

Just my thoughts. I’m not even sure if Gnome would actually gain something by adopting Qt due to the porting effort required and (tada!) it won’t happen anyway
Competition is also quite important, if only to make us listen to those damn users more, right?

Still wondering if this will yield a Nobel peace prize or the fanboy of the year award or “I can’t go to guademy 2009 ’cause the police cannot guarantee my safety”
See ya!

It being easier to make bindings for C is a complete myth. KDE currently supports:

* C++
* Python
* Ruby

Bindings for C# and PHP are nearly ready, and there’s also quite a bit of work done on supporting Javascript.