You cannot copyright an interface, as you say. There was even a court case on this, IIRC. That means you CAN include a header file meant to define the interface! It's a case of usage, not derivation. (Header files meant for internal use are a different matter).
Think of it in terms of music. Imagine a song in the public domain. You can put that song on paper with musical notation and copyright that, but you cannot claim copyright privileges against those who use your sheet music to play the song.
True, but Flash supports only three, count them, three operating systems. I'm magnanimously ignoring variations of these operating systems that are not supported (ei. 64-bit versions).
Qt supports Windows, Mac OSX, Linux, FreeBSD, NetBSD, OpenBSD, OpenSolaris, AIX, HP-UX, IRIX, S60, Hurd and LynxOS. There are a few other platforms it will also run on, but they aren't supported, so for the interest of fairness I'm leaving them out, even though the Open Source nature of Qt allows it to be ported everywhere
Qt supports four times the platforms that Flex/Flash does!
Just because some parts of the documentation refer to certain names as "keywords" does not make it so. As powerful as Nokia is, they still cannot change the compiler. There are no new keywords or G++/VC++ could not parse them!!! Really now, stop regurgitating trolls and think for a moment. If these are C++ extensions, how the hell can you compile Qt applications on standard C++ compilers? The answer is that they are not extensions. "signals", "slots" and "emit" are macros. Furthermore, they are macros that expand to nothing. The only thing Qt is doing is giving you a preprocesser called MOC that writes some object introspection code for you.
And please upgrade from "ANSI C++". Only ankle-biters user it any more. The rest of the world has upgrade to ISO Standard C++.
Re:Yeah but KDE doesn't work.
on
Qt Becomes LGPL
·
· Score: 1
My xorg.conf on one platform works fine for KDE3, GNOME, Beryl, Enlightenment, etc, etc. But for KDE4 I have to change it. Which sucks, because then it's crap for KDE3, GNOME, Beryl, Enlightenment, etc. Not every driver will have this problem, but enough do that KDE lists are forums are littered with driver related complaints.
Pretending this problem does not exist does not make it go away. I'm crossing my fingers very tightly that 4.5 will fix this.
tjstork said that installing KDE 4 automatically changed his video driver and kernel.
That is the **distribution** doing that, not KDE4. But it sort of proves my point, even the pre-packaged iso-wrapped distros that automatically replace your kernel know that the standard xorg.conf settings will not work with KDE4.
Re:Yeah but KDE doesn't work.
on
Qt Becomes LGPL
·
· Score: 1
Yes, it will build and install. That's not what I was talking about. Performance and rendering can suffer if the correct driver/config are not used.
Re:Kills any idea of using Qt in our products
on
Qt Becomes LGPL
·
· Score: 1, Flamebait
Why the heck is this modded down as a troll? Yet more evidence that the Slashdot moderation system is seriously broken.
I'll stick with ISO C++! And since Qt uses 100% ISO Standard C++, I'll have no problems!
Re:Yeah but KDE doesn't work.
on
Qt Becomes LGPL
·
· Score: 1
Furthermore, KDE doesn't depend on video drivers.
Actually it does. Even with desktop effects turned off, you can get flashies, dropouts and sluggishness if you don't have a good video driver (or correctly massaged xorg.conf settings). Much of this is actually Qt's fault, but should be fixed in Qt 4.5 with the new raster backend.
No, your app is not a derivative work of the library. GNU does not have the authority to rewrite copyright law. Just because they say it's a derivative work does not make it so. Unfortunately, GNU probably has a bigger legal team than you do. Winning in court is not about who is right, but whose lawyers are bigger.
You are incorrect. Qt is under the GPL **PLUS** exceptions allowing all commonly used Open Source licenses. Your KDE applications must be under an Open Source license, but you can choose GPL, LGPL, BSD, MIT, MPL, etc, etc.
It a perverse way, it's true. GNOME as a desktop only started as a direct result of Qt not being Free Software. That has no bearing on GNOME's current existance, of course. It's now going to have to stand on its own technical merits, however, and not hide behind silly licensing issues.
While the C++ language might have some truly scary corners, Qt hides them away from you. Unlike gtkmm, Qt mostly keeps to the mainstream object oriented parts of C++. You don't have to write functors, exceptions won't be thrown at you, etc. You may need to know what templates are in spots, but you don't need to create your own generic classes or write template specializations. Of course, some C++ "purists" hate it for that reason.
Yeah, you can do OO programming in C, but so what? You can do OO programming in assembler too! Writing GUI applications in a language meant for OO is sooooo much nicer than writing it in plain vanilla C. The premier compiled OO language is C++, which is why it is used.
Qt was (is) under the GPL+exceptions. You could write an app linking to Qt with any common FOSS license and it was okay. Only if you were proprietary developer did the licensing cause problems.
Last I looked 90 out of 100 apps written for GTK+ are GPL, of 9 of the remaining under a different FOSS license. Nothing was preventing those developers from linking their GPL applications with a GPL library.
Yet another reason not to visit "news" sites: they won't work with my operating system and browser. I'm not going to boot into Linux (or gag, Windows) just to read your stupid news. Heck, I'm not even going to switch browsers. If you can get Adobe to open source flash, so I'm not stuck trying to run a proprietary plugin meant for another OS inside a browser not approved by the cloudlords of Macromedia, then I'll consider your site. Until then, screw you and the content you rode in on.
Big cluestick: Flash is not a web standard, it's a series of incompatible proprietary plugins used chiefly to signal the presence of bad websites.
It's not about what interests you. It's about the whining. If you're one of the few sysadmins looking to work in the public school system, then the interest is legitimate. But not the whining. Discuss how Unix (not just Linux) makes a better choice for schools, discuss the hidden cost savings of Open Source software, etc, etc. But don't whine about how life is not fair.
You are too hung up on terminology. I'm an English major and it amuses me to no end to see engineers getting hung up on mere words.
Agile Software Development may be a rigorously defined term with religious adherent, but "waterfall" is not. Agile uses (not "is", but "uses") an iterative waterfall model because it is iterative and each iteration includes (but is not limited to) planning, designing, coding and testing, in that order. Of course, since you are a langauge lawyer, I have to further clarify that you can indeed test all through the process, but significant testing still occurs after the coding. Thus it's a waterfall.
People often compare software engineering with civil engineering or other stuff, and ask "why can't software be just as good?".
Actually, there's a different reason than what you cite. In nearly every other field, what you build today is remarkably similar to what you built yesterday. Most bridges civil engineers build are 95% identical to each other. Ditto for automobiles refrigerators, LCD screens, etc. But in software everything is always different. Version 1.0 is totally new. Version 2.0 adds new features that are not present in 1.0. Version 3.0 adds new features that are not in 2.0 or 1.0. And so on and so on.
I was talking about real world software development, not mythology. Test first all you want, but you still need to test afterwards. Period. Sometime after you make your last commit and before you ship, you need to test. It doesn't matter how many unit tests you wrote before coding, if you don't run them you haven't tested. You also have integration and systems testing as well, which your link blatantly ignores.
Out in the real world you'll find that successful software projects plan before coding and then test. They might not plan Z before coding A, but they damned sure planned A before coding A!
The real reason is simply because the consumer (in this case, schools) chose Windows over Linux. Is not about the price, it's about the cost. And when consumers know Windows but they don't know Linux, guess which is the lower cost? Familiarity is a desired trait. The familiarity extends beyond the school to the students' homes. Most will have Windows systems at home, and like it or not, their parents will want their children learning Windows.
But all of that is a side issue. The heart of the matter is that healthy well-adjusted people do not compete through whining. Stop worrying about what software other people are using and worry about your own life. There are far more important problems to address in life than what OS your neighbor's kids are using.
You describe the classic waterfall, the one that does not work. Your solution, "small, incremental feature based development", is in essence an iterated waterfall. You can't gather all possible requirements, but you need to gather at least one or you can't even begin coding.
Slashdot Mirror
You cannot copyright an interface, as you say. There was even a court case on this, IIRC. That means you CAN include a header file meant to define the interface! It's a case of usage, not derivation. (Header files meant for internal use are a different matter).
Think of it in terms of music. Imagine a song in the public domain. You can put that song on paper with musical notation and copyright that, but you cannot claim copyright privileges against those who use your sheet music to play the song.
True, but Flash supports only three, count them, three operating systems. I'm magnanimously ignoring variations of these operating systems that are not supported (ei. 64-bit versions).
Qt supports Windows, Mac OSX, Linux, FreeBSD, NetBSD, OpenBSD, OpenSolaris, AIX, HP-UX, IRIX, S60, Hurd and LynxOS. There are a few other platforms it will also run on, but they aren't supported, so for the interest of fairness I'm leaving them out, even though the Open Source nature of Qt allows it to be ported everywhere
Qt supports four times the platforms that Flex/Flash does!
Just because some parts of the documentation refer to certain names as "keywords" does not make it so. As powerful as Nokia is, they still cannot change the compiler. There are no new keywords or G++/VC++ could not parse them!!! Really now, stop regurgitating trolls and think for a moment. If these are C++ extensions, how the hell can you compile Qt applications on standard C++ compilers? The answer is that they are not extensions. "signals", "slots" and "emit" are macros. Furthermore, they are macros that expand to nothing. The only thing Qt is doing is giving you a preprocesser called MOC that writes some object introspection code for you.
And please upgrade from "ANSI C++". Only ankle-biters user it any more. The rest of the world has upgrade to ISO Standard C++.
My xorg.conf on one platform works fine for KDE3, GNOME, Beryl, Enlightenment, etc, etc. But for KDE4 I have to change it. Which sucks, because then it's crap for KDE3, GNOME, Beryl, Enlightenment, etc. Not every driver will have this problem, but enough do that KDE lists are forums are littered with driver related complaints.
Pretending this problem does not exist does not make it go away. I'm crossing my fingers very tightly that 4.5 will fix this.
That is the **distribution** doing that, not KDE4. But it sort of proves my point, even the pre-packaged iso-wrapped distros that automatically replace your kernel know that the standard xorg.conf settings will not work with KDE4.
Yes, it will build and install. That's not what I was talking about. Performance and rendering can suffer if the correct driver/config are not used.
Why the heck is this modded down as a troll? Yet more evidence that the Slashdot moderation system is seriously broken.
I'll stick with ISO C++! And since Qt uses 100% ISO Standard C++, I'll have no problems!
Actually it does. Even with desktop effects turned off, you can get flashies, dropouts and sluggishness if you don't have a good video driver (or correctly massaged xorg.conf settings). Much of this is actually Qt's fault, but should be fixed in Qt 4.5 with the new raster backend.
No, your app is not a derivative work of the library. GNU does not have the authority to rewrite copyright law. Just because they say it's a derivative work does not make it so. Unfortunately, GNU probably has a bigger legal team than you do. Winning in court is not about who is right, but whose lawyers are bigger.
...because Flex/Flash doesn't work on every operating system and browser.
Trolltech support was absolutely awesome. But since the Nokia aquisition it has been in a serious decline. Sigh.
You are incorrect. Qt is under the GPL **PLUS** exceptions allowing all commonly used Open Source licenses. Your KDE applications must be under an Open Source license, but you can choose GPL, LGPL, BSD, MIT, MPL, etc, etc.
It a perverse way, it's true. GNOME as a desktop only started as a direct result of Qt not being Free Software. That has no bearing on GNOME's current existance, of course. It's now going to have to stand on its own technical merits, however, and not hide behind silly licensing issues.
I've even seen Qt used with OS/2 and QNX.
While the C++ language might have some truly scary corners, Qt hides them away from you. Unlike gtkmm, Qt mostly keeps to the mainstream object oriented parts of C++. You don't have to write functors, exceptions won't be thrown at you, etc. You may need to know what templates are in spots, but you don't need to create your own generic classes or write template specializations. Of course, some C++ "purists" hate it for that reason.
Yeah, you can do OO programming in C, but so what? You can do OO programming in assembler too! Writing GUI applications in a language meant for OO is sooooo much nicer than writing it in plain vanilla C. The premier compiled OO language is C++, which is why it is used.
Qt was (is) under the GPL+exceptions. You could write an app linking to Qt with any common FOSS license and it was okay. Only if you were proprietary developer did the licensing cause problems.
Last I looked 90 out of 100 apps written for GTK+ are GPL, of 9 of the remaining under a different FOSS license. Nothing was preventing those developers from linking their GPL applications with a GPL library.
Nitpick: OpenOffice is not a GNOME application. It may use GTK+ in spots, but it is not a part of "another desktop".
Yet another reason not to visit "news" sites: they won't work with my operating system and browser. I'm not going to boot into Linux (or gag, Windows) just to read your stupid news. Heck, I'm not even going to switch browsers. If you can get Adobe to open source flash, so I'm not stuck trying to run a proprietary plugin meant for another OS inside a browser not approved by the cloudlords of Macromedia, then I'll consider your site. Until then, screw you and the content you rode in on.
Big cluestick: Flash is not a web standard, it's a series of incompatible proprietary plugins used chiefly to signal the presence of bad websites.
It's not about what interests you. It's about the whining. If you're one of the few sysadmins looking to work in the public school system, then the interest is legitimate. But not the whining. Discuss how Unix (not just Linux) makes a better choice for schools, discuss the hidden cost savings of Open Source software, etc, etc. But don't whine about how life is not fair.
You are too hung up on terminology. I'm an English major and it amuses me to no end to see engineers getting hung up on mere words.
Agile Software Development may be a rigorously defined term with religious adherent, but "waterfall" is not. Agile uses (not "is", but "uses") an iterative waterfall model because it is iterative and each iteration includes (but is not limited to) planning, designing, coding and testing, in that order. Of course, since you are a langauge lawyer, I have to further clarify that you can indeed test all through the process, but significant testing still occurs after the coding. Thus it's a waterfall.
Plan before coding and test afterwards. Duh.
Actually, there's a different reason than what you cite. In nearly every other field, what you build today is remarkably similar to what you built yesterday. Most bridges civil engineers build are 95% identical to each other. Ditto for automobiles refrigerators, LCD screens, etc. But in software everything is always different. Version 1.0 is totally new. Version 2.0 adds new features that are not present in 1.0. Version 3.0 adds new features that are not in 2.0 or 1.0. And so on and so on.
I was talking about real world software development, not mythology. Test first all you want, but you still need to test afterwards. Period. Sometime after you make your last commit and before you ship, you need to test. It doesn't matter how many unit tests you wrote before coding, if you don't run them you haven't tested. You also have integration and systems testing as well, which your link blatantly ignores.
Out in the real world you'll find that successful software projects plan before coding and then test. They might not plan Z before coding A, but they damned sure planned A before coding A!
The real reason is simply because the consumer (in this case, schools) chose Windows over Linux. Is not about the price, it's about the cost. And when consumers know Windows but they don't know Linux, guess which is the lower cost? Familiarity is a desired trait. The familiarity extends beyond the school to the students' homes. Most will have Windows systems at home, and like it or not, their parents will want their children learning Windows.
But all of that is a side issue. The heart of the matter is that healthy well-adjusted people do not compete through whining. Stop worrying about what software other people are using and worry about your own life. There are far more important problems to address in life than what OS your neighbor's kids are using.
You describe the classic waterfall, the one that does not work. Your solution, "small, incremental feature based development", is in essence an iterated waterfall. You can't gather all possible requirements, but you need to gather at least one or you can't even begin coding.