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.
"
Hey... i'll get it just for the scrolly mouse support.... I'm eager to use my scroll to go up and down (1 more thing I don't have to boot to windoze for)!
At least for pixmap theme configs.
Feel it, use it, love it, be it.
So hopefully most bugs will be fixed. BTW: just curious, did you use Gnome 1.0?
Can KDE now be included again in the debian distribution? Or are the licensing concerns still as valid as they ever were?
:( But hopefully Im wrong.
I think so
This is totally wrong. KDE CVS allows use of extensive pixmap themes. Look at the screenshots at koffice.kde.org.
Drag the same link to xfm. Doesn't work, huh? That is because Motif D'nD is not standard either. Gnome has hacks to support it. Both had to change to XDnd. Also, the KDE pixmap engine is widely believed to be faster at rendering the same pixmaps as the Gnome one. That is why they claim they will be faster. Since I don't use Gnome I can't confirm this.
Cause its sure aint the same one mentioned here :) Go read the QPL v1.0
No list traffic in months (http://lists.kde.org)
The theme engines like the rest of KDE takes advantage of inheritence. Since the base theme classes have pixmap and gradient support, that means all derived plugins also have it. Also, since these derived plugins all use the same config parser, it makes it easier to write GUI theme designer applications since there is a set of config entries you know will be supported in any plugin. Things that can be modified via this base config file include pixmaps, gradients, scrollbar position, bevels and borders, etc... Of course, you can forego all this and not use a theme engine at all. Then you get to choose from Mac(Platinum), Windows, Motif, and CDE.
Maybe I've missed it, but I thought the new QPL explicitly allows modifications and the distribution of modified versions?
The distinction between initial developer and subsequent contributors is dodgy. And the distinction between source and binary distribution is a "clear" smoke screen, wich is just there to make one fact less obvious... That for any popular branch of the original software (to get popular it will have to be distributed as a binary) the initial developer has the sole right to sell commercial licenses for the software _including_ all the patches from other parties. There is no way to branch of a truely free QT, or rather a binary of QT with truly free components. (free as in GPL/Stallmanistic free)
The entire part of the license allowing non QPL patches is essentially a pacifier, at least as far as Linux is concerned. Its practical impact is nil, unless Linux joins Free-/Open-/NetBSD in a totally source centric package distribution method. (wich might not be so bad)
Well even if it wasnt it could have been included in non-free couldnt it?
I thought the problem was the lackluster linking of KDE stuff against GPL'd stuff? And I do remember reading that the QPL although it does conform to the Debian Free Software Guidelines is still not compatible with GPL.
Qt is fine to include, but there is still debate about if KDE can be included because of GPL/QPL issues.
I don't know what he is reading, but the real QPL is at www.troll.no
These don't support pixmaps and configurable borders, etc.. They are hardcoded widget styles similar to those in Qt1.x.
Dont be so offensive, I started of by indicating I thought parts of KDE were still breaking GPL licenses.
And hell if you think they postponed QPL'd source code release to scam people out of their money than you are the one who the succesfully scammed. Im not sure what the reason was, but that one doesnt make any sense. They stand to make a lot more money if QT becomes the defacto UI library for the linux desktop, reread the QPL.
And all that being true, and the QPL being what it is. (an open source money making machine) I would still like to see KDE in debian... Because it WORKS. And I happen to think an UI library should be based on a object oriented language, indirection no thanx if I want that Ill use win32 through MFC.
QT is an excellent library but it ain't free (speech). Sometimes you just want to (must to) write some commercial software and then QT just isn't the option. GTK+ is just an awful emulation of object orientation and does not classify as a real development library. Yes-yes I know about the GTK-- and wxWindows but they are immature and poor. IMHO GNOME is inferior to KDE because it uses C. This is the technology of the 80's.
The usual AC from eastern Europe this time.
PS: I hope that the Berlin project will succeed and deoply fully LGPL compatible development libraries. The foundation of KDE is QT and that's why it's rotten.
You are missing the point, I am pointing out they kept the QPL product off the market as long as they could. And yes the way they did it SMELLS!
GNOME works, there is no justification for KDE anymore, isn't life wonderful. Besides, basing the default GUI libraries on an OO language and forcing people to use C++ to write their applications is bad. Having the option for OO programming is good, making it the default/forcing people to use it is not. 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), operator overloading etc etc.
J
That would be have been indefinately obviously.
:) Why dont you just include inheritance and be done with it?
.5%, big fuckin deal. On a system where you already start of by using X you shouldnt worry about little innefficiencies like that.
And why are you just summing up different C++ features and saying they are bad?
And what is the effect anyway? It uses 1 instead of
Apple owns the copyright for the widget set used in the QPlatinumStyle Theme. Why does Troll think that they can get away with blatantly ripping of the Mac and Windows UI? I would not be surprised if Apple and Microsoft sued them blind.
Its about time we came up with a binary level
standard. Lots of other smaller toolkit
projects are looking at themeing, and it would
be an idea to produce one working standard
that all toolkits could share and be based on.
I'd personally look at some of the ideas
that Fresco and Berlin have produced, and see
if they're interested (they've got some good
thinkers in their project).
X Windows
(two more words)
it sucks
Sun have been prevented by Microsoft from distributing the Java Windows L&F on non-Windows platforms. Yeah, it's dumb. I guess MS is just really pissed about Java.
Does this RPM work for Logitech First Mouse or just M$ IMouse?
He was making fun of Gnome (buggy, get no work done, etc... ;-)
If they had released QT 2.0 immediately, it would have been incomplete/buggy. Why exactly would you want them to do that?
Uhm, what are you talking about "Binary level standard", they are two different toolkits with two completely different API's... All you can have is config file compatibility.
I always find it funny when people say, "okay, our software stinks - why aren't you helping me then?". That may be because software that doesn't stink exists. People write software that doesn't cut it and then complain when no one wants to use it...
You could of downloaded it any time from ftp.troll.no. I love how people like to flame without a clue, it's so refreshing ;-)
Hi!
Is there a chance to get KDE 1.x to work with the new Qt?
You can check for the changes on the Troll page. They even have a porting howto, but the changes to the old classes aren't so dramatic.
But the Qt book probably takes (most of) the changes into account, as the Qt2 CVS was open for several months.
At least there is a short introduuction to Qt 2 in the book.
The way Qt (and thus KDE) refers to them is a style is a non-configurable widget look usually made directly out of deriving virtual paint methods (like the built in styles), while themes are something the user can configure via a config file.
The whole thing is not so much about GPL and KDE in general. As long as the GPL'd code is written specifically for KDE, there is an 'implicit consent' by the author that this is ok. The whole discussion is merely about the 'alien' code some KDE apps use (don't know about kghostview).
According to KDE developers, this is only a very small percentage, but I don't know how much effort it'll be to replace it.
I've read on kde-devel about Thorben Weis et al. hacking the QTL as a replacement to the bloated SGI STL. Together with the KDE libs this makes up an impressive framework, I'd say.
I haven't downloaded Qt yet, so I can't tell you if this works or not, but it seems as if it isn't including stdarg.h
Is QT 2.0 thread-safe?
What support does it have for interprocess communication? Are there classes for pipes or shared memory?
That being the case, it's pretty hard to defend. Signal/Slots are just a tiny little part of a GUI toolkit. As far as all these users, how many real apps are written in Gtk--?
Anyone know if KDE 1.1.2 will suport Qt 2.0? And since XFree86 3.3.4 and gcc 2.95 will be released in a week or two, why not wait to compile Qt 2.0 later? The only Qt based application I have today is Qps and I really don't know if it's source compatible with the new Qt. Licq is? Wait!
Just downloaded the rpm, and installed it and now the only thing not working on my mouse is the 4th button (going over to xfree86.org to look up how to enable it now!) did have to add imwheel & to my .xinitrc file though, but that's not a big thing.
Nowhere are those quotes *anywhere* in the QPL!! That has been commented on several times yet the article gets ranked a 4??? Looks like prejudice to me.
Doh! Qt2.0 uses the QPL, which is a free license.
The entire above post is not true, none of those quotes are in the QPL. Moderating it up to 4 instead of putting it at 0 or -1 is either moderation abuse or moderator ignorance.
Did anybody else notice that today the price went up from $1200 to $1500 for the Windows (non-free)
version? I was just teetering towards buying it, now I don't know.
>[no text]
well if that isn't a grand paradox....
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)
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
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.
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. =>
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. :-)
--
yeah just like its FUN to be an NT admin...you get to waste a lot of time installing and reinstalling NT on the boxes...and it keeps you perpetually in a job (CEO: "What? The Linux boxes have been working without a hitch for the past 7 months? Fire the admin, we dont need him anymore.")
"There is no spoon" - Neo, The Matrix
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...
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).
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'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.
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))
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
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
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..
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.
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.
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.