Slashdot Mirror
qt 2.0 released
kris writes "Those funky Trolls up there north have released Version 2.0 of the Qt library.
Unlike Version 1, this one is available under the QPL Open Source license, which is in compliance with the Debian Free Software Guidelines and qualifies as Open Source. Qt 2.0 also contains tons of changes and improvements, such as Unicode support, better I18N, rich text, theming and thousands of other things. You want to download their stuff to give it a try.
"
Don't start that nasty bickering again.
Pixmap themes: Will be compatible (Mosfet working on that)
As for more advanced theme engines: Qt/KDE styles offer more control and flexibility than gtk, e.g. the geometry of sliders etc (AFAIK gtk slider 'grips' have to be symmetrical or even in the middle).
But as few themes really use even the capabilities gtk offers, this will probably not be of high importance.
Drag and Drop:
In reality, GTK+ (and therefore GNOME) supported as many DnD standards as possible, while KDE decided to go it alone.
Nonsense, similar to the "WM independent" stuff.
KDE uses the Offix protocol (developed for this 'oddice suite'), Gnome/gtk another exotic one,XND IIRC.
Why didn't they use Motif DnD? Because it sucks: much too complicated, yet not powerful.
Gnome implemented Motif DnD for compatibility (mainly with Netscape) later, and recently it seems to work properly.
In KDE there is currently somebody implementing Motif DnD (for Empath?), and this may go into KDE 2 as well. So much for being liberal.
But the new XDnD protocol is a real chance for Unix/X, and should be taken.
And BTW, "parity with GTK+"? For theming, perhaps, but for the rest, gtk still has to do some homework...
B/A
Of course you can distribute modified versions.
The KDE Team tries to have a developers release
of KDE based on Qt2.0 out by the end of this summer.
A stable KDE release based on Qt2.0 can be
expected in the first quarter of '00.
Those who don't mind hacking a bit themselves
can of course always have a look at the
tgz-snapshots or follow KDE development from
day to day via CVSup.
KDE development has been based on beta versions
of Qt 2.0 for some time already. As of today
all development will be based on the released
version of Qt2.0.
Cheers,
Waldo Bastian
bastian@kde.org
I've read the QPL. I do like some of it's ideas. First and foremost the requirement that the Free Edition is limited to use with the X Window system is a wonderful idea. But it seems like Troll Tech wants to force requirements on people that it isn't willing to undertake itself. For instance, the QPL states that the author of programs using the QPL has to allow others to make modifications to their programs and they have to allow others to redistribute the modified version of their program. This all sounds well and good, but Troll Tech isn't willing to submit to the same restrictions. Specifically with regards to QT:
people are forbidden from distributing modified versions of QT,
and their programs can't require a user to make changes to QT.
So, while the license is somewhat better, it ain't the GPL (any version); and I still have hope for the Harmony Project.
_____
It's ironic that Microsoft's goal is to write good software and Linux's goal is world domination.
It appears that the 'stuff' url on the short description should be ftp://ftp.troll.no/qt/source/qt-2.00.ta r.gz
I am a lawyer and this constitutes legal advice and I shall indemnify you against any losses arising from taking it.
I'm guessing there are at least a hundred, and possibly as many as a thousand KDE contributers, and wouldn't all of them have to agree to have their segments relicenced? If i'm correct that would be one hell of a hard task, especially knowing how many GPL purists there are.(i'm not a real fan myself)
This is important to me, as I'm devloping some free software and am at the point where I need to choose a toolkit. I'd like to release under GPL, and I'd like to use QT, as it is the most "C++" toolkit I've found (wxWindows is not _quite_ as nice, IMHO).
Okay, I'm not going to speak in any official capacity here, but after all the conversations I've read on debian-devel and the #Debian IRC channel, here's the situation as I see it:
Debian does not and will not immediately include KDE, even with the release of the DFSG-free Qt 2.0, because KDE's license, namely the GPL, does not allow linking with libraries with licenses other than the GPL.
The GPL also includes this clause:
The problem with this is that if KDE and Qt 2.0 are both put into main, then the second part of this clause ("unless that component itself accompanies the executable") comes into effect. I'm not sure exactly about what happens if KDE is put into another section, but then, I'm sure that's been discussed also, and anyway, if it were in another section, it wouldn't be part of the official Debian distribution, anyway.
So one of the following has to happen, I believe, before KDE can be included:
I believe 3 has been looked at, and been decided against. I believe that Joseph Carter is working with KDE to resolve that part of the problem, and if they is successful, then it will be included.
Anyway, if I'm wrong in any way, I'm sure someone will correct me... this is just as I understand it.
However while the QPL is in fact a free license, it is not compatible with the GPL used by KDE. Of course, it's not the first free license to have this problem---the BSD license isn't compatible with the GPL either. I tried to make the QPL compatible with the GPL, but the methods I was able to offer them for this compatibility would have left them open to things such as immediate forks made just to spite them. Before the final license was published, I was was convinced their fears were not in the least unfounded. Fortunately the fires have cooled a bit now and hopefully in the future they won't have anything to fear from a GPL compatible Qt if not directly a GPL'd Qt. Time will tell.
In the meantime, there are two options which I see available to actually solve the compatibility issue:
If you are looking for the best way to grant permission to a GPL program, feel free to email me.
It's a shame too because it's possible that at some point in the future, the GPL would make an excellent license for Qt. I'm not going to lose hope in the Qt license becoming GPL compatible at some point, however I'm pretty certain they won't put Qt under the GPL itself. Perhaps in time Troll Tech may consider the license I've been working on and plan to present to kde-licensing and debian-legal RSN for opinions and other hashings.. I'm going to make the license not specific to KDE at all because I really believe other people are likely to find the licence more suitable to them than the GPL for a number of projects. Protection of the software is going to be a focus of the license (much like the GPL), however I think the results will be more "social". It will be compatible with the current QPL and pretty much any DFSG/OSD compliant license for that matter. This is a design goal.
hmmm, perhaps I should quit typing about the damned thing and finish writing it? =D
Unfortunately no, at the time I couldn't come up with a way to make the thing GPL compatible and still protect KDE from malicious action that a number of people were threatening. Right now I want to work on the KDE license since there is still a real legal issue left to hash out. I'm trying to address this with a new license since the KDE team is about as happy with the GPL at this point as Troll Tech is, for much the same reasons. They'll undoubtedly be happier with the license I'm working on when it's finished. If it works out well and we can't blow any large holes in it, perhaps Troll Tech may be able to be convinced to adopt the license. I'm not going to push for that now though, it's their call. Qt is now free and I'm personally satisfied with that. GPL compatibility would be nice, but I want to be sure that the license is going to be successful first. I also want the legal issue to be settled and have been settled awhile first.
To be quite honest, if Troll Tech starts considering a new license which is GPL compatible, I will advise against it if I'm still getting mail like I have been over the past six months. Hostile, not infreqnetly threatening, usually riddled with poor spelling and grammar, and just plain obnoxious hate mail. And this for working damned hard to take a piece of non-free software and give it a free license. More than once I've been accused of compromising the ideals of free software because I couldn't live without something that worked like windoze...
For the record, I don't even use or like KDE. I am just happy with my console and screen. X is a waste of resources and a desktop environment more so. So then why am I doing it? Because free software is important to me. And because I'm sick of the ritual flamefests on the subjects to the lists.
It will happen. If I have to contact just about all of them myself, they will be consulted. Particularly those whose code was simply borrowed and used for KDE.
I think the provision in the QPL preventing this is quite deliberate. It didn't occour to me at the time that Troll Tech would have wanted it this way for a reason, but I probably wouldn't have been too quick to change it if I had realized---especially given that you still can do in-house software with Qt freely, but if Troll Tech asks for the source you have the provide it. If your code is that secret that you aren't willing to give it out, it's essentially proprietary IMO and Troll Tech doesn't want you using Qt to write anything proprietary without paying for it. The license I'm working on for KDE will be more GPL-like on this matter and will allow you to develop in-house software without distributing it. Of course you'll still be bound by the QPL's requirement that you publish source if Troll Tech asks for it.
Don't I wish! You have any idea how much headache I would be spared if this were the case!? Eesh! No, the system library thing only applies if you're not distributing the thing with the library in question. Debian distributing KDE and Qt together in main makes that clause not apply. Even then it's a badly worded clause and I don't like it much. I've pleaded with RMS to rewrite it for the sake of clarity and sanity in the GPL v3. Hope he listened.
Oh, we can include Qt now as part of the system sure... However we couldn't distribute KDE ALSO as part of the system. Kinda annoying, that. I've no intention of giving up getting both Qt and KDE into main just yet, however. Qt 2.0 can go into main anytime now. KDE needs more work. When I'm done with the work in question (may take a few months before EVERYTHING is done), if one cannot get a KDE built for Qt 2.x, I'll try to convince Troll Tech to QPL the latest 1.x version for us. =>
I certainly hope they are going to get permission for this license change from all the people who have contributed code to KDE, or else remove that person's code. Changing the license on somebody else's code without their permission is a definite no-no.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
It really is shaping up to be a nice package. Already, at pre-alpha stage, you can see the vast improvement of konqueror over kfm. When you pick up an item in the current kfm, there is a noticeable delay, and some disk thrashing. When you pick up an konqueror object, *bang*, you have it immediately. The drag-and-drop should be very fast and smooth.
Currently, most things compile (the switch from Qt 1.4x to 2.x caused a bit of a setback in this regard, but it of course had to be done some time). I believe the current thought is to bundle KOffice with KDE 2.0. KOffice is shaping up to be a commercial-grade office productivity suite. KWord looks very, very nice, and should have most, if not all, of the functionality of the big boys (plus DTP functionality). KPresenter is a presentation program vis-a-vis PowerPoint. KIllustrator is a Corel Draw-type vector graphics program. There are a number of other smaller programs in there. The only thing that probably is a bit feature-starved (from my brief perusal of it) would be KSpread, the spreadsheet program. It's fairly simple, and doesn't have all the doo-dads of Excel or StarCalc.
All in all, KDE 2.0 will be a fantastic Unix desktop environment! As a subscriber to kde-devel, I can tell you that the KDE developers are serious about avoiding bloat whereever possible, and creating a desktop that anyone can use, not just programmers and/or sysadmins.
While a lot of people gripe about Microsoft's dominance, the KDE team, rather than complain, are doing something about it. KDE 2.0 (as well as GNOME) will definitely make Linux and Unix a desktop contender for the masses. And with the price advantage, I predict it will start putting the hurt on Microsoft's market share.
Needless, to say, I see it as a good thing. :-)
--
Pardon me, but this seems *extremely* hypocritical. You want to write binary-only software (presumably for pay), and you criticize Troll for wanting you to pay them for their software.
Despite its flaws, that is probably the best thing about the QPL; it discourages closed software, and makes those who would write closed software pay for the privilege. For that reason, I like it better than the LGPL (but I still prefer plain old GPL).
--
>This assumption is generally done by people who do not know the effects of using bad OO techniques such as templates (just look at what it does to your cache)
What the Sam Hill do templates have to do with your cache? A template in C++ is essentially a super, type-checked macro with the ability of specializations for specific data types. It can and should be compiled to as efficient code as non-templated stuff. (In the variants of Java with templates, the template handling is basically done as a pre-process.) The only cost, if the compiler/linker is competent, is to the programmer in terms of extra link time to eliminate duplicate template function instantiations.
>operator overloading
Can be wonderful. Can also be misused, but so can many other things.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
>Look at the code it generates then.
That's rather like slamming the internal combustion engine because Yugos are crap. If no compiler handles templates well, then that means it's a feature ahead of its time, not that it is inherently awful.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
I'd really like to see Qt become more of an application framework rather than just a widget set. When working on a Qt project, I got very caught up in just getting a good solid framework created. I still have hardly even started on the project.
(I'm not the type of coder to just bang out code, it's got to be done right.)
Seems like the only free framework we've really got is wxWindows and, while not bad, there are a lot of things I don't like about it.
Well, I'm having problems getting Qt to even compile. I've got an Alpha Tru64 workstation, but the main problem is with egcs/gcc (--version='egcs-2.91.66'). It has problems with the QString class. It warns of an implicit declaration for va_start on line 10922, and then procedes to report a bunch of parse errors. Any ideas?
You *do* run Red Hat, don't you?
No. But how arrogant of you...
Did I use Gnome 1.0? Nope. Matter of fact, I didn't pick up Gnome till about 1.0.6 or so.
As for Qt getting out of beta, there's one thing. Lots of people don't use betas very much, but everyone immediately grabs for the 1.0 releases. It's as though your testing pool suddenly quintupled. THey'll find bugs you missed the first time, guaranteed. Even the Linux kernel isn't immune to this; if I remember correctly 2.2.1 came out only a day after 2.2.
Actually, they still count as themes.
:)
As I understand it, a "theme" is simply one "look" which can be set once such that all apps which support that theme style will then use it.
For GTK, these are Default, Redmond95, Notif, and Pixmap.
This also means that the "themes" we commonly see at gtk.themes.org are, strictly speaking, usually not themes in the strictest sense of the word; rather they are configurations of the Pixmap theme plus the necessary graphics to make the configuration run. I suppose "skin" would be a better term for those types of themes: a GUI widget configuration for one program, which in this case is the Pixmap theme. Because that program is itself a theme, Pixmap skins act like themes.
"Themes" sound cooler than "skins" anyway
Actually, it's another abuse of the patent system. This one is called a "design patent" and it really does simply put a patent on look and feel. Apple's got loads of them, including Platinum, Hi-Tech, Gizmo, Drawing Board (I think), and loads of others that no one really knows why they have since even Apple doesn't use them.
If I could remember the patent numbers I'd post links to them. In any case, I'd imaging M$ has patents on the look and feel of Win95 and 98 too (though why would you want to patent such bad stuff?)
Either way, you're discounting the possibility that perhaps they licensed the looks from Apple and M$. Unlikely, to be sure, but possible (little-known fact: Apple actually had purchased licenses for all the GUI stuff they took from Xerox. M$ did not have licenses for what it took from Apple).
Anyway, that's the thing there. Troll might get sued for it. Then again, I don't think either Apple or M$ will bother to do it.
I won't be downloading it (not because of any GTK zealotry; I'm waiting for 2.0.1 and all the inevitable bug fixes the Troll guys missed). Besides, I have a few questions concerning themes:
1) How compatible are the themes with those from GTK (at least for pixmap-based themes; I know the engine-based themes have no hope of compatibility)? It'd be nice if I could use the same theme for all my apps, and since work on Qt's themes didn't even start until after GTK's was cemented the only reason to make them incompatible is for incompatibility's sake.
2) Assume that GTK and Qt themes are incompatible (which is likely, unfortunately). How easy is it to convert the themes between toolkits? Might we be seeing a program in the future to do this?
3) Suppose the second isn't possible. Might it be possible for either toolkit to eventually gain the ability to read in the other's theme format?
As you can see, my biggest concern is interoperability between the two. While I don't have any Qt/KDE apps (never saw the need for any of the current batch, again I don't consider myself a zealot) it'd really be nice to use them seamlessly with GTK/Gnome apps (this is also why I'm pushing for a common desktop API which both KDE and Gnome could support, so a developer could write the code once and support both DE's. XDND is a start, but drag-and-drop isn't the only thing which needs the help a common API gives).
Actually contrib is the place for free-but-depending-on-non-free software.
I thought the problem was the lackluster linking of KDE stuff against GPL'd stuff?
The core problem is the interaction between Qt's license and KDE's (GPLed). It can be solved by changing KDE's license, but that will mean replacing the third-party GPLed code in KDE, or getting it relicensed, which may prove difficult.
And I do remember reading that the QPL although it does conform to the Debian Free Software Guidelines is still not compatible with GPL.
Indeed. Essentially, the GPL requires that code linked to by a GPL-ed piece of software be under the GPL or under a license that imposes no more restrictions than the GPL (like public domain, the MIT license, or BSD without the ad clause), except when that code is part of a major system component (something like a proprietary Motif or C library in an environment where they're always present (think Motif on SUN)).
X doesn't qualify as such a component (you can have a perfectly working Linux system without it, and X is not part of all distributions), so Qt, a layer over X, doesn't either. And Qt's license, now the QPL, imposes more restrictions than the GPL (e.g. the "patch requirement" that modified versions may only be distributed as original code + separate modifications).
No. Qt can (and will) however now be included in Debian proper ("main"), rather than being available in "non-free".
Or are the licensing concerns still as valid as they ever were?
The licensing concerns are that Qt's license is incompatible with KDE's (GPL). This has regrettably not changed with the QPL. Knghtbrd, one of Debian's developers, provided a lot of input to Troll Tech regarding the QPL, but they couldn't be convinced to make the QPL GPL-compatible.
If the licensing issue had been about Qt1's non-freeness by itself, KDE could simply be in the "contrib" section. But the licensing issue is an interaction between licenses that prevents us from redistributing KDE binaries.
Luckily, there are strong indications that the KDE developers will be changing KDE's license to one that does not interact badly with the QPL (e.g. an Artistic-like license); once that happens, KDE can go in Debian proper.
What Qt 2 being free means to Debian is that Qt itself will now become a part of Debian proper, and that Qt-using software that doesn't suffer from the licensing issue (e.g. like pi-address, which is GPL + exception clause) can go in Debian.
Im currently using matching E and GTK themes. The 'looks-cool' factor is very important for me and Ive tolerated the sluggishness that comes with it so far. However, I cant help but wonder why the hell these simple graphics take so damn long to draw. Its not like were doing dozens of layers of alpha blending or animated fractal generated height map rendering with environment mapping and specular highlighting from multiple colour animating, moving lightsources. Actually, I feel my P2-400 should manage that just fine. It can certainly scale and display a few pixmaps faster than this.
I should stop whining and do something about it. Too bad I'm such a lazy sob :-)
--
Fuck the system? Nah, you might catch something.
I haven't actually read the QPL yet, however, it sounds like it is compliant with the Debian Free Software Guidelines (and therefore, the Open Source Definition), so I don't see why not.
If you feel that Gtk-- is immature and poor, why don't you stop by and help mature it. We are currently in a major overhaul mode which makes much of our code autogenerated (improving the maintainablity which is the downfall of so many wrappers.) We are reintegrating it with the recently released libsigc++ library, which is a very modern C++ callback frame. It can use a lot of grunt work converting over procedures and improving the code generator.
If you can't see that the underlying language that the code is written in is irrelevent (if though is given how to make wrappers easily), then I don't see what will convince you. By the way much of the berlin code I have looked at is wrappers on the C OpenGL API. So saying things that use C are inferior hits a lot more than you know.
--Karl Nelson
Second, we have a large number of users so obviously it does stink all that much. The reason for writing free software is in general dissatisaction with what is currently available, something the first author was obviously expressing. Or because writting code is fun and enjoyable hobby, certainly that is my reason. Or perhaps that not everyone is going to stop using gtk+ tomorrow and some people would just as well use C++ with the gnome framework.
Personally, I find the Qt signal system to be poor compaired to what is possible. It lacks the flexibly of a full callback system and requires a code generator to parse the code. Both of which are definite drawbacks. And if you for some reason think that I don't know what I am talking about go visit my comparison between Qt's signal system and my own. Qt's system may be nice but one can do far better. (Of course one peice does not the whole make.) They can certainly turn arround tomorrow and use libsigc++ in Qt, of course that only proves my point that people should always be working on alternatives.
--Karl
Who? I am one of the main authors, go look on the authors pages. If you are referring to Guillaume Laurent comments, I suggest you go back and reread. He said that all wrappers have problems with maintainablity and that they don't solve all the problems. Neither of these imply the Gtk-- can't be a good C++ widget set. Only that there are problems that must be addressed.
Signal/Slots are just a tiny little part of a GUI toolkit.
Huh, whenever someone points out the great features of Qt they always place the signal/slot mechanism as one most the important features. I consider the intergration of printing and drawing systems to be a close second. The fact that I call my system a callback framework insulted some of the KDE developers. (Signal is too overloaded already.) So it is a very important piece. Without signal/slots most of the ease of use goes out the window.
As far as all these users, how many real apps are written in Gtk--?
As with any free kit, who knows! Unless people mail you saying we use this or place that fact prominently on their web site, there is no way to know. Since I released the libsigc++, I have only now discovered that 4 projects were using the old Gtk-- signal system (without Gtk--) in their projects. Had they not mailed me with comments, I would likely have never known unless I sat down to compile one of them.
Do you seriously think that all projects which compete with a more mature product are a waste of time?
--Karl
First of all just because A exists doesn't mean that B is {useless, unjustified, worthless, ...}. There is always room for two competing products. Without such competition progess slows and stagnates (refer to Microsoft). Saying "GNOME works, there is no justification for KDE anymore" is exactly the same logic that someone used to tell me that Gtk-- wasn't needed because Qt existed. Qt does not exclude gtk+, KDE does exclude GNOME. There can be coexistance.
Second, templates can be used as a strength to make code much, much better. On the other hand it can be used to blow both legs clean off. It can produce faster and smaller code then C. On the other hand one can produce large, slower more bloated code with it. Does that mean it is bad? No. The irony of this is that gtk+ uses macros like templates more that Qt uses templates at all! (there are only 16 templates in all of Qt.)
--Karl
I'm wondering when the new KDE will be released, now that QT is out. Also, what new features will it have?
___
If you think big enough, you'll never have to do it.
AFAIK KDE won't allow pixmap themes ... to me this is no great loss, they are too slow anyway. Mostly the pixmap themes just serve to give Gnome a rep for being slow (and most are very poorly thought out, with black text on dark backgrounds)
support gun control: take guns from cops
Read the page at
http://www.troll.no/changes/2.0.html. It is not binary compatable. You must recompile Qt programs for use with 2.0. It is not 100% source code compatable; some things have changed.
Your password has expired, please login to change it.
What would be the point of booting into Windows to use the scroll wheel when you'd be using different programs anyway? Duh!
I don't think this is pixmap themes in the GTK sense. If I remember correctly, all themes are implemented using a dynamic library via virtual functions. These libraries can use pixmaps themselves if they wish. Correct me if I'm wrong on this, it was a while since I read it.
Then you get to choose from Mac(Platinum), Windows, Motif, and CDE.
;)
Thank God for themes then
That's excellent. (although gtk+ pixmap themes are slower then slow, even on accelortated X / fairly fast machine).
Personally, I agree theme engines are the future, since they are flexable and fast. In GNOME I reguluarly use Ice Theme or the GTKstep theme, just because these theme engines are fast.
Speed and snappiness (looks nice), is a important aspect to get new users to fall in love with Linux.
I am extermely excitied about Qt 2.0, just because the technology is cool and, Qt has reputation of being a solid good toolkit.
And, I am also looking at GTK 2.0, that should have some great improvements too.
Qt really has a strong and brigth future, with commerical developers helping to pay for it's improvements, and free (freedom, not price) developers, who make wonderful applications like KDE or KOffice.
Don't worry about it, Ivan E. Moore II has a great selection of apt-get'able KDE packages:
http://kde.tdyc.com/Debian/
People please read http://www.troll.no/qpl/plaintext.txt and see the truth for yourself. The QPL is a very simple license. It is the simplest license I have ever read, it is much simpler than the GPL. It is simpler than many postings here on slashdot, it is simpler than this posting. It is in plain english. You will understand it much better by reading it than by reading postings here.
people are forbidden from distributing modified versions of QT
No, no, no, no! I can't believe this crap has been ranked up. It is so blatantly false. Did you read the wrong license? Please follow my link.
Firstly distribution takes place as one of two forms either distribution of binaries or distribution of source code.
Clause 4 (of 6) allows you to distribute binaries of modified versions of QT under the following 3 conditions
a) You must include the license document.
b) You must make the source code available.
c) You must place all your modifications under the same license (the QPL).
Note that the distribution of binaries under the QPL protects your freedoms better than the GPL does, because the QPL contains no "privacy loophole".
Clauses 2 and 3 (of 6) allows you to distribute modified versions of the source code. Clause 2 allows me checkout the original QT from any CVS repository (or copy it off any CD). Clause 3 allows me to CVS update (or apply a patch script on a tar file of modifications) to update to a modified version of QT (source code).
That is clauses 2 and 3 allow you to distribute modified versions of the QT source code under reasonable conditions. There is no problem here!
Okay onto your next point
and their programs can't require a user to make changes to QT.
A honestly don't understand what you are trying to say here. If your program requires the user to use a modified version of QT then distribute a binary version of your modified QT along with your program.
while the license is somewhat better, it ain't the GPL (any version); and I still have hope for the Harmony Project.
I have news for you.
1) The GPL ain't perfect.
2) None of the Harmony Project source is under the GPL, it is under the LPGL.
Not that I'm against the harmony project, BTW.
If you are going to complain about the QPL please find something worthy of complaining about!
Now I'm no Troll Tech lackey. I admire the GTK toolkit and have great respect for those who developed it. If you are a GTK/GNOME supporter and want something to complain about, then complain about this:
The QPL makes it harder to reuse code than the GPL or BSD licenses do. Clause 3 of the QPL effectively prevents you from taking a bit of Troll Techs QT code and including it in your own program. The QPL is an "indivisible" license if I may be permitted to coin a phrase.
Personally that is a feature of the QPL I really don't like but I'm prepared to live with given the great work (code) that the Trolls are producing.
I hoped this cleared a few things up. (Well I know full well that in another couple of weeks the same people will just post the same crap again, but at least I got to reread the QPL and double check my facts (again))
Oh christ, templates again. Look idiot, from Ada to Haskell to variants of Java (Pizza), Generic Programming is a good thing, it's here to stay, and atavists who insist on going back to assembly with drum memory and tape drives for all are not going to change that. Tell me, do you have ANY formal background in CS to qualify your wild assertions about what ideas of programming are good or bad?
I've finally had it: until slashdot gets article moderation, I am not coming back.
> QT is an excellent library but it ain't free (speech).
Tell that to RMS, who has blessed it with the Free Software moniker.
I've finally had it: until slashdot gets article moderation, I am not coming back.
The situation is by far not as clear as you present it here.
And you are not sufficiently up-to-date concerning the QPL.
Indeed. Essentially, the GPL requires that code linked to by a GPL-ed piece of software be under the GPL or under a license that imposes no more restrictions than the GPL (like public domain, the MIT license, or BSD without the ad clause)
The problem is, that this is a very arbitrary interpretation of the GPL except when that code is part of a major system component (something like a proprietary Motif or C library in an environment where they're always present (think Motif on SUN)).
Qt is for Caldera/Corel/easyLinux/etc. what Motif is for SUN.
X doesn't qualify as such a component (you can have a perfectly working Linux system without it, and X is not part of all distributions), so Qt, a layer over X, doesn't either.
Motif is a layer over X just like Qt. There is no difference wrt licensing.
And your definition of system component is your own, not that of the GPL. The GPL doesn't say *essential* component. It even mentions the compiler, although a precompiled Linux runs very well without one.
And Qt's license, now the QPL, imposes more restrictions than the GPL (e.g. the "patch requirement" that modified versions may only be distributed as original code + separate modifications).
That's not true anymore. This was the case in the first draft of the QPL, which was heavily critizised for that. The QPL 1.0 only demands that new code is clearly marked as such with info about the coder. The GPL requires the same.
There is no "patch requirement" anymore, at most a patch or CVS recommendation.
Even RMS admitted that, and you should too.
The only remaining problem RMS saw was the "non-non-disclosure" issue. You can't use QPL'd code secretly in-house without notifying TrollTech, while the GPL allows for such quasi-proprietary development.
I'm not quite sure if this is rather a loophole in the GPL than a flaw of the QPL.
Sure you can use the system library exception.
Qt is NOT part of the regular KDE packages (check for yourself).
It is expected to be present on the system (and it mostly is).
Debian's problem with KDE was that they couldn't include Qt as a 'system component' as long as it didn't conform to the DFSG.
Now that Qt 2 is DFSG-free, Qt can be a system component and the respective clause can be applied.
With a little bit of imagination, one could probably find a way to use this as a loophole to develop "in-house" applications that are in fact propritary programmes.
With huge international corporations like DaimlerChrysler 'in-house' could be quite big. So you could make additional contracts between (independent) divisions that prevent free distribution without some sort of payment...
That way, companies could 'steal' GPL'd code with this clause (they couldn't distribute it outside of the company, but that is not wanted anyway in some cases - the 'intra-corporation' market is big enough).
I'm not sure if this could be prevented somehow, but the danger is there, and getting rid of it is not necessarily such a bad thing...
KDE is just to neat and clean. Its getting to be like the rest of this Linux stuff, it works without a hitch. I need software that chrashes and gives me problems so I've got excuses for not getting any work done.
Dennis
Who owns your data?
AFAIK it includes both qt 1.4 and 2.0 branches.
Just peek at www.oreilly.com, they know.
---
The day Microsoft makes something that doesn't suck,
---
I'm going to live forever, or die in the attempt.
KDE provides a ton of useful app framework objects... try out the new version of KDevelop and you'll even get templates for doc/view structured apps :)
http://www.cs.uni-potsdam.de/~smeier/kdevelop/
No, it's still not the GPL. What did you expect? The Artistic license isn't GPL either. Nor is the MPL. Come to think of it, the LGPL isn't the GPL either!
If you're demanding that every license be the GPL, then methinks you have a lot of growing up to do. The QPL is open source. No, it's not 100% free, but neither is the GPL! I, for one, am grateful that Troll Tech is sharing their code with me.
The reason that Troll Tech has some difference from the GPL is that Troll Tech actually makes money off of Qt. The don't want someone going off and selling a different version of Qt. Neither do they want to support someone else's implementation of it. They are quite up front about this. Qt belongs to Troll Tech. They don't want code forks. Compare this to the continuing recriminations about XEmacs.
If everyone who bitched about Qt would have contributed to the Harmony project, it would have been done last year!
A Government Is a Body of People, Usually Notably Ungoverned
It's your code. You are the licensee. You can do whatever you want. The GPL imposes restrictions on the "licensee", but it is legally impossible for it to impose any on the original developer, the licensee. If it did, it would not be a license, it would be a contract.
But thinking of your users, go ahead and use the Qt library. You can certainly consider it a "system library" if it comes with your operating system. It comes with most (Debian, Redhat, Slack, SuSE, Mandrake,...).
But it really doesn't matter if it's a system libary or not. Qt is not part of your source code. It is not your module.
The GPL is very clear that you can dynamically link with any libary, GPL, QPL or anything else.
A Government Is a Body of People, Usually Notably Ungoverned
Nobody took much of an interest in the Qt license until KDE became popular. Before then, it was just another non-GPL library, like xforms. After KDE became popular, there was some worry that Qt might become essential for the GNU System. The reactions to this were varied. Some politely asked Troll to be a bit more liberal in their licensing. This action got Troll's attention, and they released Qt under the QPL open source license.
But other actions also got Troll's attentions. They were deluged in hate mail. By "hate mail" I mean vitriolic, obscene and threatening communications. Everytime the subject of Qt or KDE came up on a forum, religous bigots would crawl out of the net to lambast them yet again.
As a group, the GNU community told Troll, "you're not wanted."
Well, Troll Tech heard. In the future, Qt might be released under a BSD or Artistic like license. But it will never, ever be released under the GPL.
A Government Is a Body of People, Usually Notably Ungoverned
GTK+ has had mouse support since 1.2.0. Thats why gnome and GTK+ apps has the wheel support.
Is this qt lib 100% backwards compatible with the old qt? Can I go in and axe my non-gnu qt lib and put my system at peace (I don't have KDE installed, I really only installed qt for licq)?
This actually makes licq GNU-friendly. I like that. And hopefully, KDE will be made GNU-friendly as well..
Tell me, do you have ANY formal background in CS to qualify your wild assertions about what ideas of programming are good or bad?
Not to be terribly picky, but since when does owning a slip of sheepskin -- or the persuit of such -- make one better qualified to make assertions, wild or no?
I take exception to the idea that some self-styled elite knows what's best for me and the real world. In fact, I find it downright humorous, given that a noticable portion of the formally educated folk I know are essentially spreadsheet jockeys, and most of the best programmers and systems architects I know are graduates of U of Hard Knox.
And there's nothing like the anecdotal evidence of your own two eyes.
Here you can find an iwheel rpm.
You *do* run Red Hat, don't you? If not, use alien or something.
To make it work, you'll have to make a few changes to your XF86Config file (add the line "ZAxisMapping 4 5" to the Pointer section for your mouse).
After that, just run imwheel and stuff should just magically work. Run "imwheel -k". Read the docs in /usr/doc/iwheel* for more info.
"imwheel", bro. Feel it, use it, love it, be it.
Flame bait. Just say NO.
--
I've been looking at picking up that O'Reilly Qt Programming book. It is for the older version AFAIK. Did the API drastically change, or will I be safe picking this up.
Thanks.
If Windows became open-source, I'd bet that within a few years it might actually become a usable system. At the very least, if the source was released (all of it, not just pseudo-open-source), then projects like WINE would be greatly helped along. Imagine how fast WINE development would take off if they didn't have to feel around in the dark.
So, while I probably wouldn't use Windows if it became open-source, I would be very pleased because I'd be able to run MS Office under Linux using WINE. (Eventually)
Very good point!
Linking Netscape with GTK is no problem, because the NPL allows it. However, linking any GPL'ed gnome apps with the NGLayout library would be exactly the same situation as linking a GPL'ed app (say KGhostView) with QT.
Of course the authors of such a Gnome app can resolve the problem by simply relicensing any app which calls NGLayout under a looser license.
The difficulty for the KDE developers is that some of their apps include GPL'ed code, and therefore cannot be relicensed without replacing the GPL'd code.
(The same problem *may* exist for some Gnome apps, but remember all KDE apps need QT, only a few Gnome apps use NGLayout).
It would be useful to have a list of all the KDE apps which include GPL code. It is possible that Debin could distribute KDE by simply throwing out some of the apps.
Kevin (running KDE 1.1.1 for now, but not KGhostView)
The article mentioned above (about KDE 2.0 and KOffice) is still wrong.
Both KDE 2.0 and GNOME 1.0 have a theme engine system. Both of them use theme support from a DSO, and include a DSO for pixmaps themes. The article would love you to think that KDE will be fast, because it doesn't use pixmaps. In reality, most theme authors are lazy, and most themes will use the pixmap engine.
For GNOME there are already some clean, fast theme engines, and there's no reason to believe it will be any different for KDE 2.0 -- but that's still months away. Likewise there are slow, bloated themes for GNOME, as there will be for KDE.
It's also misleading (deliberately perhaps) for the KDE developers to talk about KDE and GNOME "standardising" on a drag-and-drop protocol. In reality, GTK+ (and therefore GNOME) supported as many DnD standards as possible, while KDE decided to go it alone. This is finally fixed by Qt 2.0.
Try this, right now, in your Desktop Environment: Go into Netscape, and drag a URL icon onto the desktop or task bar. Doesn't work? Sorry, your desktop environment doesn't agree with "Be liberal in what you accept".
Nick.
I think I heard after Qt 2 was announced as OSS that Debian was considering including KDE as an option. I have no clue whether they actually will or not, though.
> I'm not quite sure if this is rather a loophole in the GPL than a flaw of the QPL.
:-)
The GPL gives you the *freedom* to develop in-house without releasing source. It only demands you release source if you distribute the program. I think that is an important freedom- the choice to *not* distribute your program/code.
This provision of the GPL is a feature, not a bug.