Really, was it really necessary to mention that Slashdot comment? Slashdot is full of articles and very objective and doesn't start all that many flame wars at all. That comment was the work of one single poster!
Why did you have to mention it and blame all of Slashdot? Are you trying to slam Slashdot again? Or are you trying to make it look as if the Slashdot guys are trying to start a flamewar?
I'm sure I will get blah blah blah. You shouldn't encourage more gratuitous slams of Slashdot. Quit trying to make Slashdot look bad. Jeebus.
Hey, why do you have to 'believe' anyone? Why don't you look at the evidence provided by both and consider the relevant context and decide for yourself what you think. Why must you have the truth fed to you and why do you refuse to think and make up your own mind?
Ballmer and Petreley are offering facts/opinions/conclusions and you have been given a brain to question and analyze these assertions. Use them.
Abandoning your inate ability to question and look at the world through your own eyes in favor of blindly 'trusting' whomever based on past precedent is not such a good strategy for getting through life.
It is almost certain that Ballmer *sometimes* tells the truth and I'd be very suprised if Petreley hasn't lied at some point to someone or other, so take this into account along with all the _evidence_ you can glean and see for yourself.
... or, the government could get serious and just close all the loopholes and we could have a sane energy policy.
It's like that new do not call list with the giant loophole for 'surveys'. I can't wait to see the conservs/libertarians spouting this as an example why government regulation doesn't work... sheesh. Well yah, if you have a huge freaking loophole then it's *designed* not to work!
You know many government regulations on consumers and business work just fine even in the face of enormous demand and wealth. The Iraqi people are amazingly rich in Oil yet they starve and go hungry even in the face of overwhelming demand for food because of government regulation.
And that's why the only appropriate remedy for this or any of the other illegal anti-trust actions is to fine Microsoft *heavily*. This will serve as a powerfull more anti-competitive actions and it is decidedly in the interest of consumers. The key really is making the fines large enough for the shareholders to demand accountability from Microsoft.
In the end money is the prime motivator for Microsoft and hitting them in the pocketbooks is the only way to make sure they _listen_. With everything else MS will just wiggle around and delay until the 'remedy' is void of any real teeth.
"I have not said, OOP in GObject C is inherantly better than OOP in Qt/C++. I said it was more practical for the real world, because it makes it easier to reuse code. Big difference."
You have said, "The main sticking point seems to be GObject, but I've yet to find a KDEer elucidate what is so bad about it, especially considering it was designed with language bindings in mind." and then you went on to state that GObject is scary. The bindings you talk about are a red herring. Seems you've elucidated it yourself.
Regardless, your post does not in anyway explain how GObject makes it easier to reuse code then QObject. Really you confuse yourself and start comparing apples to oranges... comparing COM and CORBA to QObject. Your Jabber client example has no relation at all to what we are talking about.
As for the licensing of KParts that you take issue with I'd like to note your long and tortured hair pulling about Apple using an LGPL'd shared lib for the new browser. http://dot.kde.org/1041971213/
It doesn't really matter because I don't wish to convince you or any other GNOME developer to use QObject in GNOME. Have some respect and grant us the same understanding.
...just like, why is the media play in KDE in c++, when really that kind of thing is better off in python imo)."
Why? Can you give any reasons to back up your opinions? Why should a media player be written in python over C++ as a general rule?
Partly that's because KDE is C++ only. I think these C vs C++ arguments are pretty silly, neither of them are all that great for desktop apps, even games!
You keep insisting on repeating this error no matter how many times it is pointed out to you that it is not true. One more time for the record: You don't need to program in C++ for KDE if you don't want to. We have bindings and they are all advancing. I don't know whether you really intend to have your 'C++ is bad for desktop apps' taken seriously. If so then LOL.
Hey read the other posts. I've offered to educate you on the difficulties of binding to Qt. It's not really hard. Licensing issues are your own problem. I see no need for KDE to bend over for GNOME on licensing again.
Ok, now you admit that GObject is scary. No more posts on why C is just as good as C++ for this stuff.
QObject simply isn't shareable, not without huge pain that makes GObject look like a walk in the park. Not only just C++ lovelies, but licensing and such as well."
Ok, as someone who binds to QObject I will educate you that it is not hard. It is relatively painless and the resultant object model is wonderful for other object oriented languages like Python, Java and C#. Really, if you are concerned about this come and talk to me sometime.
Not only just C++ lovelies, but licensing and such as well."
Hey, if you and the rest of GNOME and the GNU project have a problem with the KDE/Qt licensing (LGPL/GPL) then I can safely say that is not really our problem anymore. FSF is fine with Qt licensing and actually prefers it for shared libraries. You'll have a tough time generating sympathy for proprietary developers from us.
"I wouldn't normally name names, but it's starting to get very irritating."
LOFL - Laugh Out Freakin Loud.
Even if you were a KDE developer I would find such a statement extremely silly. I mean you are a GNOME developer and now you are worrying because KDE doesn't want to use GObject? Come on! How about you go and ask the gnome development list to use QObject and then report back how irritated you are with the small but vocal minority that might disagree. Truly one of the most amusing comments I've seen Mike;-)
"I'd note that while KDE may be more integrated, your average KDE desktop is not..."
I don't know on any 'average KDE desktop'. The only thing I know is that my KDE desktop is very integrated. The apps that we have now will only improve and I currently do not lack for any feature. BTW, you can use different languages to develop KDE applications right now. We support Perl, Python, Java and C# and others so this is not really a useful argument. Besides, the difficulty of writing all this shared infrastructure and rearchitect KDE is enormous compared with the difficulty of binding the current architecture to other languages. It is not really that much more difficult than binding to C.
It is ironic because Qt is now GPL which is in accordance with the stated preference of the FSF and the GNU project. GNOME is part of the GNU project.
GNOME was started because Qt was not free. Now, Qt is free, but GNOME developers are concerned for the proprietary developors who might wish to create third party apps.
The irony presented in all it's glory:
"For example, they may appeal to the ego, promising "more users for this library" if we let them use the code in proprietary software products. Popularity is tempting, and it is easy for a library developer to rationalize the idea that boosting the popularity of that one library is what the community needs above all."
Hey like i've said earlier I don't really mind using glib if a good technical reason exists not to use the Qt equivalent. I haven't really seen anyone give a good reason why we should depend upon a new library when the current ones provide the same functionality. If such a reason exists then ok.
This is different from another proposal being floated by Havoc and a few others where GNOME and KDE would share much more tech. Again, no problem, but to me the exclusion of Qt/C++ from this shared tech is a non starter.
Actually, I'd really like to see that.:-) However, that's really not related. Look at what glib does."
Yah, I have no real problem with glib. But, I do object to using a bunch of shared technologies between GNOME and KDE when all the shared technologies are devoid of Qt/C++. It is just to radical to say that KDE should now start over and start using all C based infrastructure just so that KDE and GNOME can share stuff. KDE is already mature and has a good strategy. No compelling reason exists to remove Qt from KDE. Just the thought of it makes me shudder.
They are far superior when it comes to an object oriented development environment. Code reuse is a good thing and C++ has support for object orientation in the language itself. Now, while it isn't necessary for everything, it certainly is the best solution for a desktop. KDE is more integrated and one of the major reasons is the use of Qt/C++.
BTW, I don't take the 'KDE is perfect, GNOME sucks' attitude. I prefer KDE, but this choice does not in and of itself disparage GNOME. Plenty of opportunities for improvement on both sides.
In general I found myself agreeing with Aaron 's comments more than the others. The main problem I see with Havoc and Waldo and all the others pushing for more shared technologies across the desktop is the implementation technology. KDE is built from the ground up upon Qt/C++ and this is one of the major reasons for it's considerable success. I see no reason to change this winning strategy.
Recently, we've been discussing the incorporation of Glib into KDE on the core development list. While I am not against this per se, I wonder whether the GNOME developers will ever allow the use of Qt/C++ in any shared technology. It seems to this day that Qt licensing is still a problem for GNOME. One of the greatest ironies in all of Free Software, IMHO.
If Havoc and Waldo are serious about integration then this problem will have to be addressed in earnest. I do not want to see KDE come down a level in technology just so that GNOME apps can integrate into KDE. Better to improve the great applications we currently have in KDE then waste so much time focusing on some elusive merging of these two.
Besides, choice is good and GNOME with KDE offer this. Where we can agree upon specs and closing superficial differences we should and that will help those who choose to use GNOME apps in KDE and vice versa. But please, let's not rearchitect KDE and strip it of Qt.
And that is not what the I wrote. I said that Sun was rethinking Linux strategy which is exactly what the quote conveys. They are also trying to spread FUD about the SCO case in order to boost Solaris stock at the expense of IBM. Read the linked article.
Please present any evidence or argument why the KDE Free Qt Foundation is a 'myth'. Until you do I will continue to understand that you are just a troll interested in bashing something which you do not like.
It does not help your case when you continue to purposefully associate Trolltech with SCO when it has been pointed out *many* times that the Canopy Group invests no more than ~5% in Trolltech. They neither 'own' nor 'control' Trolltech.
If Trolltech ever discontinues licensing Qt as GPL then it automatically can be licensed under the BSD. This is the purpose of the KDE Free Qt Foundation. This has been all worked out long ago:
http://www.kde.org/whatiskde/kdefreeqtfoundation .p hp
Quit spreading this stupid FUD. You are making yourself look very silly. Qt is Free Software licensed under the GNU GPL. Trolltech has no way to 'turn the screw' and Qt would be released under the BSD license if they did. Besides, Trolltech is one of the most graceful and pleasant Free Software companies around. They have given and given to the community and we have no reason to mistrust them. The SCO connection is dubious at best since they have invested at most 5%.
LCMBoy, while I agree with your sentiments, it is important to be clear and precise since so many are confused about the GPL and Trolltech. This is doing a great disservice to the community.
"All they ask is that if you want to make money from your Qt-derived stuff, they get a licensing fee."
This is not ture. You are of course free to make money on Qt without paying Trolltech a licensing fee. Qt is under the GPL which is commercially friendly. It is not friendly to _proprietary_ developers and this is where Trolltech get's a license fee.
Slashdot Mirror
Really, was it really necessary to mention that Slashdot comment? Slashdot is full of articles and very objective and doesn't start all that many flame wars at all. That comment was the work of one single poster!
Why did you have to mention it and blame all of Slashdot? Are you trying to slam Slashdot again? Or are you trying to make it look as if the Slashdot guys are trying to start a flamewar?
I'm sure I will get blah blah blah. You shouldn't encourage more gratuitous slams of Slashdot. Quit trying to make Slashdot look bad. Jeebus.
I am much more liberal than Dean, but his aggressive adherance to the facts and his penchant for standing up to the current administration have made me a solid supporter. I've been blogging for Dean (various sites) and have volunteered for his campaign for various activities including the New Hampshire Democratic Convention. For more information on Dean, check out Blogforamerica (Dean's official blog, Unofficial Dean Blog, The DailyKOS (Great left leaning blog that covers the primaries).
From the article, "The PC outperformed the similar Macintosh machine, at an impressive rate."
Quit apologizing and making up excuses. Adobe is using the term PC on the page to refer to non-Apple computers running Windows.
Hey, why do you have to 'believe' anyone? Why don't you look at the evidence provided by both and consider the relevant context and decide for yourself what you think. Why must you have the truth fed to you and why do you refuse to think and make up your own mind?
Ballmer and Petreley are offering facts/opinions/conclusions and you have been given a brain to question and analyze these assertions. Use them.
Abandoning your inate ability to question and look at the world through your own eyes in favor of blindly 'trusting' whomever based on past precedent is not such a good strategy for getting through life.
It is almost certain that Ballmer *sometimes* tells the truth and I'd be very suprised if Petreley hasn't lied at some point to someone or other, so take this into account along with all the _evidence_ you can glean and see for yourself.
... or, the government could get serious and just close all the loopholes and we could have a sane energy policy.
... sheesh. Well yah, if you have a huge freaking loophole then it's *designed* not to work!
It's like that new do not call list with the giant loophole for 'surveys'. I can't wait to see the conservs/libertarians spouting this as an example why government regulation doesn't work
You know many government regulations on consumers and business work just fine even in the face of enormous demand and wealth. The Iraqi people are amazingly rich in Oil yet they starve and go hungry even in the face of overwhelming demand for food because of government regulation.
And that's why the only appropriate remedy for this or any of the other illegal anti-trust actions is to fine Microsoft *heavily*. This will serve as a powerfull more anti-competitive actions and it is decidedly in the interest of consumers. The key really is making the fines large enough for the shareholders to demand accountability from Microsoft.
In the end money is the prime motivator for Microsoft and hitting them in the pocketbooks is the only way to make sure they _listen_. With everything else MS will just wiggle around and delay until the 'remedy' is void of any real teeth.
"I have not said, OOP in GObject C is inherantly better than OOP in Qt/C++. I said it was more practical for the real world, because it makes it easier to reuse code. Big difference."
You have said, "The main sticking point seems to be GObject, but I've yet to find a KDEer elucidate what is so bad about it, especially considering it was designed with language bindings in mind." and then you went on to state that GObject is scary. The bindings you talk about are a red herring. Seems you've elucidated it yourself.
Regardless, your post does not in anyway explain how GObject makes it easier to reuse code then QObject. Really you confuse yourself and start comparing apples to oranges... comparing COM and CORBA to QObject. Your Jabber client example has no relation at all to what we are talking about.
As for the licensing of KParts that you take issue with I'd like to note your long and tortured hair pulling about Apple using an LGPL'd shared lib for the new browser. http://dot.kde.org/1041971213/
It doesn't really matter because I don't wish to convince you or any other GNOME developer to use QObject in GNOME. Have some respect and grant us the same understanding.
SuSE, "That said, we want to very clearly and unequivocally voice our support of the ideals and goals of UnitedLinux and the Linux community."
So, how do you interpret this to mean that SuSE is backing out of UnitedLinux?
...just like, why is the media play in KDE in c++, when really that kind of thing is better off in python imo)."
Why? Can you give any reasons to back up your opinions? Why should a media player be written in python over C++ as a general rule?
Partly that's because KDE is C++ only. I think these C vs C++ arguments are pretty silly, neither of them are all that great for desktop apps, even games!
You keep insisting on repeating this error no matter how many times it is pointed out to you that it is not true. One more time for the record: You don't need to program in C++ for KDE if you don't want to. We have bindings and they are all advancing. I don't know whether you really intend to have your 'C++ is bad for desktop apps' taken seriously. If so then LOL.
Hey read the other posts. I've offered to educate you on the difficulties of binding to Qt. It's not really hard. Licensing issues are your own problem. I see no need for KDE to bend over for GNOME on licensing again.
"Yeah, I know GObject is scary."
Ok, now you admit that GObject is scary. No more posts on why C is just as good as C++ for this stuff.
QObject simply isn't shareable, not without huge pain that makes GObject look like a walk in the park. Not only just C++ lovelies, but licensing and such as well."
Ok, as someone who binds to QObject I will educate you that it is not hard. It is relatively painless and the resultant object model is wonderful for other object oriented languages like Python, Java and C#. Really, if you are concerned about this come and talk to me sometime.
Not only just C++ lovelies, but licensing and such as well."
Hey, if you and the rest of GNOME and the GNU project have a problem with the KDE/Qt licensing (LGPL/GPL) then I can safely say that is not really our problem anymore. FSF is fine with Qt licensing and actually prefers it for shared libraries. You'll have a tough time generating sympathy for proprietary developers from us.
"I wouldn't normally name names, but it's starting to get very irritating."
;-)
LOFL - Laugh Out Freakin Loud.
Even if you were a KDE developer I would find such a statement extremely silly. I mean you are a GNOME developer and now you are worrying because KDE doesn't want to use GObject? Come on! How about you go and ask the gnome development list to use QObject and then report back how irritated you are with the small but vocal minority that might disagree. Truly one of the most amusing comments I've seen Mike
"I'd note that while KDE may be more integrated, your average KDE desktop is not..."
I don't know on any 'average KDE desktop'. The only thing I know is that my KDE desktop is very integrated. The apps that we have now will only improve and I currently do not lack for any feature. BTW, you can use different languages to develop KDE applications right now. We support Perl, Python, Java and C# and others so this is not really a useful argument. Besides, the difficulty of writing all this shared infrastructure and rearchitect KDE is enormous compared with the difficulty of binding the current architecture to other languages. It is not really that much more difficult than binding to C.
Ugh. How many times do we need to see this?
"To make commercial apps w/ Qt, you have to pay a liscence for the QPL version since GPL doesn't allow commercial use."
The GPL has absolutely no problem with commercial use. It is really disheartening to see this. I guess MS's FUD had more of an affect than we thought.
It is ironic because Qt is now GPL which is in accordance with the stated preference of the FSF and the GNU project. GNOME is part of the GNU project.
GNOME was started because Qt was not free. Now, Qt is free, but GNOME developers are concerned for the proprietary developors who might wish to create third party apps.
The irony presented in all it's glory:
"For example, they may appeal to the ego, promising "more users for this library" if we let them use the code in proprietary software products. Popularity is tempting, and it is easy for a library developer to rationalize the idea that boosting the popularity of that one library is what the community needs above all."
(http://www.fsf.org/licenses/why-not-lgpl.html)
Hey like i've said earlier I don't really mind using glib if a good technical reason exists not to use the Qt equivalent. I haven't really seen anyone give a good reason why we should depend upon a new library when the current ones provide the same functionality. If such a reason exists then ok.
This is different from another proposal being floated by Havoc and a few others where GNOME and KDE would share much more tech. Again, no problem, but to me the exclusion of Qt/C++ from this shared tech is a non starter.
Actually, I'd really like to see that. :-) However, that's really not related. Look at what glib does."
Yah, I have no real problem with glib. But, I do object to using a bunch of shared technologies between GNOME and KDE when all the shared technologies are devoid of Qt/C++. It is just to radical to say that KDE should now start over and start using all C based infrastructure just so that KDE and GNOME can share stuff. KDE is already mature and has a good strategy. No compelling reason exists to remove Qt from KDE. Just the thought of it makes me shudder.
They are far superior when it comes to an object oriented development environment. Code reuse is a good thing and C++ has support for object orientation in the language itself. Now, while it isn't necessary for everything, it certainly is the best solution for a desktop. KDE is more integrated and one of the major reasons is the use of Qt/C++.
BTW, I don't take the 'KDE is perfect, GNOME sucks' attitude. I prefer KDE, but this choice does not in and of itself disparage GNOME. Plenty of opportunities for improvement on both sides.
In general I found myself agreeing with Aaron
's comments more than the others. The main problem I see with Havoc and Waldo and all the others pushing for more shared technologies across the desktop is the implementation technology. KDE is built from the ground up upon Qt/C++ and this is one of the major reasons for it's considerable success. I see no reason to change this winning strategy.
Recently, we've been discussing the incorporation of Glib into KDE on the core development list. While I am not against this per se, I wonder whether the GNOME developers will ever allow the use of Qt/C++ in any shared technology. It seems to this day that Qt licensing is still a problem for GNOME. One of the greatest ironies in all of Free Software, IMHO.
If Havoc and Waldo are serious about integration then this problem will have to be addressed in earnest. I do not want to see KDE come down a level in technology just so that GNOME apps can integrate into KDE. Better to improve the great applications we currently have in KDE then waste so much time focusing on some elusive merging of these two.
Besides, choice is good and GNOME with KDE offer this. Where we can agree upon specs and closing superficial differences we should and that will help those who choose to use GNOME apps in KDE and vice versa. But please, let's not rearchitect KDE and strip it of Qt.
And that is not what the I wrote. I said that Sun was rethinking Linux strategy which is exactly what the quote conveys. They are also trying to spread FUD about the SCO case in order to boost Solaris stock at the expense of IBM. Read the linked article.
Please present any evidence or argument why the KDE Free Qt Foundation is a 'myth'. Until you do I will continue to understand that you are just a troll interested in bashing something which you do not like.
It does not help your case when you continue to purposefully associate Trolltech with SCO when it has been pointed out *many* times that the Canopy Group invests no more than ~5% in Trolltech. They neither 'own' nor 'control' Trolltech.
If Trolltech ever discontinues licensing Qt as GPL then it automatically can be licensed under the BSD. This is the purpose of the KDE Free Qt Foundation. This has been all worked out long ago:
n .p hp
http://www.kde.org/whatiskde/kdefreeqtfoundatio
Quit spreading this stupid FUD. You are making yourself look very silly. Qt is Free Software licensed under the GNU GPL. Trolltech has no way to 'turn the screw' and Qt would be released under the BSD license if they did. Besides, Trolltech is one of the most graceful and pleasant Free Software companies around. They have given and given to the community and we have no reason to mistrust them. The SCO connection is dubious at best since they have invested at most 5%.
Keep your petty Trolltech FUD to yourself please.
Read the linked article. The quote comes near the bottom where news.com talks with John Loiacono, a VP at Sun. find/grep is your friend ;)
This is not ture. You are of course free to make money on Qt without paying Trolltech a licensing fee. Qt is under the GPL which is commercially friendly. It is not friendly to _proprietary_ developers and this is where Trolltech get's a license fee.
commercial != proprietary