The README is irrelevant. Besides, it means that the license only applies to the X11 version. That does not prohibit you from porting it to Windows yourself.
Re:Perhaps this is paranoia talking, but...
on
KDE Strikes Back
·
· Score: 1
Yes, throwing together the beta-announcement and the opinion-piece by dep (who likes to stroke the flames once in a while, remember the Corel-Anti-KDE-conspiracy theory of his from a while back?) looks a bit like that old saying from/about the press: "only bad news are good news"...
Small correction: it's kwin now (and it looks like anything you want it to, due to the new style-plugins).
Re:KDE Team Steps Up Marketing Effort
on
KDE Strikes Back
·
· Score: 1
Yep, because we're busy fixing bugs (and some people have even got a life besides computers;), and we don't have to keep a schedule if we think the product isn't ready yet...
So yes, you wait longer, but you also get a more polished product.
a) Qt existed before a majority of compilers even supported templates, let alone the std::-library.
b) QString uses UniCode, std::string doesn't. QString also provides reference counting and copy-on-write (yeah, I know that this can be bad in certain situations in multi-threaded environments etc., but it's also much more efficient in the normal case)
Great. So I can't navigate my filesystem in comfort and have a shell command line at the same time.
Of course you can. Konqueror just has the additional ability to embed a terminal window... (please read before you post, I said it can contain a view that is Terminal window).
Sorry, but C (and C++) pass parameters strictly by value. Passing args "by pointer" is not the same as pass-by-reference, as the pointer itself is a distinct datatype that is passed by value.
C++ adds pass-by-reference (with the postfix "&"), and a reference type seperate from the pointer type, but that's not the "default".
While I haven't found a link to the script, there are several sources (like this) that list the quote as
Roy:I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the
dark near Tannhäuser Gate. All those moments will be lost in time like tears in rain. Time to die.
Note the spellings "C-beams" and "Tannhäuser" (which is an opera by Richard Wagner)!
No, when you install a current distro you get GNOME 1.0X and KDE 1.1.2...
Besides, distros are notoriously laze, I released an update for KSysV (under KDE 1.1.x), do you think one distribution would have packaged it? No, they all use the outdated version from the KDE_1_1_BRANCH... *nirg*
OK, not Unicode but for wide character languages (those with many symbols like Chinese), my fault. Anyway, yes you could easily create a basic_string with some large enough character type (QChar? *g*).
STL is the common name, I know it's all part of the std:: library, but even Stroustrup talks about "the STL" in "The C++ Programming Language", so I guesst that's ok;)
As for the containers, the new value-based containers (QMap, QValueList,...) work almost exactly like their std:: counterparts interface-wise, including iterators and all, only the (older) pointer-based ones don't (because of source compatibility).
wchar_t is what you're looking for, it's even in the standard.
Problem: still not all compilers support the whole std:: library (for example gcc's stdc++-library is far from complete).
And it would mean that a bug in a vendor's std:: library could lead to arbitrary behaviour in Qt (guess who would get the blame?). Oh, I'll shut up now and just quote from the FAQ:
15. Why does not Qt use STL?
The Standard Template Library, contrary to what the name implies, is not all that standardized (at least not yet); implementations differ, and some systems/compilers do not even have it yet. We prioritize very highly that Qt-based programs should be completely and easily portable across platforms and compilers, so we don't want to put STL-dependency in Qt until it is safe to do so.
As for the string class, in Qt 2.0 there is a brand new QString class which is much more usable and efficient (using implicit sharing instead of explicit) than the 1.x QString, as well as covering internationalization through Unicode. The STL string is less usable and efficient.
Still, it is no problem to use STL together with Qt, if you prefer. QStrings can easily be converted to STL strings and vice versa. Using the Qt tool classes (lists, stacks and so on) instead of the STL classes is optional, not obligatory.
The only "problems" I know of are people arguing over perceived license conflicts, yet you implicitely compare KDE to Microsoft "throwing code at a project and no one knows what does what".
If that's what you intended, it's slanderous and completely uncalled for, if not, please don't phrase things that way...
Because those weren't available on all platforms when Qt was written (it has always been cross platform, earlier versions had both macro- and template-based containers, for those compilers that didn't support templates back then).
Besides, QString is UniCode (while std::string is not, since it's just std::basic_string) and reference counted, so you get a performance bonus as well.
As for bidirectional scripts: there's some support in KDE I think, but as I don't speak any of the involved languages I'm not too sure about it, ask someone. Heck, write to Trolltech and ask them to pay you for writing it!
Just imagine for a moment that there's more than one "OSS business model". Heck, what Trolltech is doing now is an OSS business model, just different from what Red Hat.
Whether one is better than the other is a different question, but I don't think you can deny the logic of Warwick's line of reasoning: we don't WANT to rely on programmer's being not "unscrupulous or lazy" (indeed, Larry Wall features "laziness" as one of the programmer's virtues;-), if we could do that we could rely on offerings like Plan 9 "in the spirit in which they were given".
As has been pointed out there, that's not acceptable. Why use a different measure here? Actually people critisized the early Qt Free Edition license for exactly this reason (resulting in the KDE Free Qt Foundation). Disregarding that earlier criticism now seems like desperately finding something "evil" about everything and everbody that has got to do with Qt in some way, shape or form...
Though your reasoning seems to be more sane in this post than in your initial one, I still fail too see how it could be too late NOW, after you've just stated "Granted this day won't come within this year, or the next,...".
Especially since "this day" only means 55:45, according to what you said. *wonders*
I've got no idea, maybe they were working on this change for a long time, maybe not...
In any case, it's clear why the article was published now, as a response to Carter's. What I fail to see is, how this necessitates the events described by you.
I could do it with a Perl script in five minutes, including the time it takes to write the script. They never struck me as being too arrogant to admit their mistakes; I've seen them do it in the past. If they've kept decent records, they should still have contact information for the developers, not a single one of which would refuse to make the program legally distributable.
Unfortunately it's not so easy... Email addresses have the tendency to become invalid over the course of the years, and some parts of a few KDE applications originated outside the KDE development community.
For example, I grudgingly grant explicit permission to link KSysV with Qt (grudgingly because I don't think this permission is necessary), yet I haven't seen KSysV included in Debian, yet...
Slashdot Mirror
...which is not for unicode but for "wide-char" languages (mostly the asian ones, with > 255 chars)
The README is irrelevant. Besides, it means that the license only applies to the X11 version. That does not prohibit you from porting it to Windows yourself.
You have to rely that Trolltech will allow you to port your (GPLed) application to these systems.
Not true. You have to rely on Trolltech to port Qt to these systems (and I don't think the license even says that, regardless of the README).
No one is hindering you in porting your application.
You don't get sarcasm, do you?
;)
Or was that anti-sarcasm?
Yes, throwing together the beta-announcement and the opinion-piece by dep (who likes to stroke the flames once in a while, remember the Corel-Anti-KDE-conspiracy theory of his from a while back?) looks a bit like that old saying from/about the press: "only bad news are good news"...
Small correction: it's kwin now (and it looks like anything you want it to, due to the new style-plugins).
Yep, because we're busy fixing bugs (and some people have even got a life besides computers ;), and we don't have to keep a schedule if we think the product isn't ready yet...
So yes, you wait longer, but you also get a more polished product.
Because
a) Qt existed before a majority of compilers even supported templates, let alone the std::-library.
b) QString uses UniCode, std::string doesn't. QString also provides reference counting and copy-on-write (yeah, I know that this can be bad in certain situations in multi-threaded environments etc., but it's also much more efficient in the normal case)
Yeah, completely proprietary. You can't even look at Qt's code without paying fees to the Trolls, the Free-KDE-Qt-Foundation doesn't exist either.
Or did you mean the closed source libkdetopsecretstuff.so.2.0?
Hey pal, pass over some of the crack you've been smoking...
Great. So I can't navigate my filesystem in comfort and have a shell command line at the same time.
Of course you can. Konqueror just has the additional ability to embed a terminal window... (please read before you post, I said it can contain a view that is Terminal window).
It spits out XML.
An UI compiler (uic) converts that to C++ code.
What the poster meant is that
a) Konqueror can be started as root from the Panel.
b) it can contain a view that is a Terminal window, i.e. the content pane is replaced by an embedded terminal.
Sorry, but C (and C++) pass parameters strictly by value. Passing args "by pointer" is not the same as pass-by-reference, as the pointer itself is a distinct datatype that is passed by value.
C++ adds pass-by-reference (with the postfix "&"), and a reference type seperate from the pointer type, but that's not the "default".
While I haven't found a link to the script, there are several sources (like this) that list the quote as
Note the spellings "C-beams" and "Tannhäuser" (which is an opera by Richard Wagner)!
But the parentheses still suck.
(And yep, I have written programs in LISP)
No, when you install a current distro you get GNOME 1.0X and KDE 1.1.2...
Besides, distros are notoriously laze, I released an update for KSysV (under KDE 1.1.x), do you think one distribution would have packaged it? No, they all use the outdated version from the KDE_1_1_BRANCH... *nirg*
OK, not Unicode but for wide character languages (those with many symbols like Chinese), my fault. Anyway, yes you could easily create a basic_string with some large enough character type (QChar? *g*).
;)
...) work almost exactly like their std:: counterparts interface-wise, including iterators and all, only the (older) pointer-based ones don't (because of source compatibility).
STL is the common name, I know it's all part of the std:: library, but even Stroustrup talks about "the STL" in "The C++ Programming Language", so I guesst that's ok
As for the containers, the new value-based containers (QMap, QValueList,
wchar_t is what you're looking for, it's even in the standard.
Problem: still not all compilers support the whole std:: library (for example gcc's stdc++-library is far from complete).
And it would mean that a bug in a vendor's std:: library could lead to arbitrary behaviour in Qt (guess who would get the blame?). Oh, I'll shut up now and just quote from the FAQ:
What problems are you speaking of?
The only "problems" I know of are people arguing over perceived license conflicts, yet you implicitely compare KDE to Microsoft "throwing code at a project and no one knows what does what".
If that's what you intended, it's slanderous and completely uncalled for, if not, please don't phrase things that way...
Sorry, I posted as "plain text", nonetheless got omitted from
std::basic_string<char>,
sorry for that.
Because those weren't available on all platforms when Qt was written (it has always been cross platform, earlier versions had both macro- and template-based containers, for those compilers that didn't support templates back then).
Besides, QString is UniCode (while std::string is not, since it's just std::basic_string) and reference counted, so you get a performance bonus as well.
As for bidirectional scripts: there's some support in KDE I think, but as I don't speak any of the involved languages I'm not too sure about it, ask someone. Heck, write to Trolltech and ask them to pay you for writing it!
Just imagine for a moment that there's more than one "OSS business model". Heck, what Trolltech is doing now is an OSS business model, just different from what Red Hat.
Whether one is better than the other is a different question, but I don't think you can deny the logic of Warwick's line of reasoning: we don't WANT to rely on programmer's being not "unscrupulous or lazy" (indeed, Larry Wall features "laziness" as one of the programmer's virtues ;-), if we could do that we could rely on offerings like Plan 9 "in the spirit in which they were given".
As has been pointed out there, that's not acceptable. Why use a different measure here? Actually people critisized the early Qt Free Edition license for exactly this reason (resulting in the KDE Free Qt Foundation). Disregarding that earlier criticism now seems like desperately finding something "evil" about everything and everbody that has got to do with Qt in some way, shape or form...
Speculative indeed!
Though your reasoning seems to be more sane in this post than in your initial one, I still fail too see how it could be too late NOW, after you've just stated "Granted this day won't come within this year, or the next,...".
Especially since "this day" only means 55:45, according to what you said. *wonders*
I've got no idea, maybe they were working on this change for a long time, maybe not...
In any case, it's clear why the article was published now, as a response to Carter's. What I fail to see is, how this necessitates the events described by you.
I could do it with a Perl script in five minutes, including the time it takes to write the script. They never struck me as being too arrogant to admit their mistakes; I've seen them do it in the past. If they've kept decent records, they should still have contact information for the developers, not a single one of which would refuse to make the program legally distributable.
Unfortunately it's not so easy... Email addresses have the tendency to become invalid over the course of the years, and some parts of a few KDE applications originated outside the KDE development community.
For example, I grudgingly grant explicit permission to link KSysV with Qt (grudgingly because I don't think this permission is necessary), yet I haven't seen KSysV included in Debian, yet...