Home > Qt > Qt# 0.7.1 Released Qt# 0.7.1 Released Eugenia Loli 2004-03-25 Qt 39 Comments Qt# is back: a new build system has been hacked into place to avoid dependency on Portable.NET’s csant. Miscellaneous bugfixes have also been made to this version. About The Author Eugenia Loli Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker. Follow me on Twitter @EugeniaLoli 39 Comments 2004-03-25 9:26 am I started using QT a few weeks ago, and I love it ! .NET is a superb platform, so I must say this looks very interesting 🙂 Has anyone started using this for ‘real’ ? How’s it working ? 2004-03-25 9:48 am You like QT? For your interest: QT was chosen as base for Novell’s new desktop development. German IT-Newsticker heise.de reports that. 2004-03-25 9:54 am Great. Chris Stone revealed yesterday at BrainShare that it is already decided that Qt is the standard development toolkit for Novel. Because some Novel projects already deploy .NET (i.e. mono) I can imagine that Qt# will see more attention (and maintainance?) in the future. Sadly I myself haven’t yet the time to play with Qt# but it’s somewhere on my Todo list. 🙂 2004-03-25 10:12 am I have played round with and looked at a few GUI toolkits, these include Gtk, Gtkmm, Gtk#, QT and WxWidgets. The easiest in my opinion is Gtkmm. Unfortunately I think there are so many different languages and GUI toolkits available that it is making virtually impossible for Distribution venders to manage them all. I recently started looking at QT a while back but gave up because of the lack of a free-edition for Windows. Does anyone know if trolltech will ever release a free-edition for Windows. 2004-03-25 10:13 am Hm, I wonder what would happen if Novell decided to buy Trolltech… Would they re-license it to LGPL? 2004-03-25 10:16 am http://members.shaw.ca/dkite/mar192004.html Search for “KDE integrates mono” This set is based on the SMOKE library (a library designed to make it easy to write KDE bindings). They should support the KDE classes too. 2004-03-25 10:29 am Hm, I wonder what would happen if Novell decided to buy Trolltech… >>>>>>>>>>>> But I don’t think that they plan to buy Troll Tech and relicense Qt. I don’t see how this will make their profit bigger. Why do people fancy Novel as a kind of Robin Hood? Nothing could be further away from reality. 2004-03-25 10:36 am – GTK+ is LGPL – GTK# is LGPL – Qt is GPL/QPL and you can buy a commercial license – GNU Classpath (http://www.classpath.org) is GPL with a special exception but Qt# is only GPL! Thats the main problem of Qt# I see. It is not allowed to create programs on top of Qt#, which are not GPL-compatible. And there are no possibilities to buy an other license. So, Qt# looks nice. But to assert, it need a complete rewrite in an other license I think. Rulf 2004-03-25 10:39 am But if Novell buy Qt and release it under lgpl to linux and gpl for windows, and start to shell Qt to windows for real price (~ $400) IMHO it can realize bigger profit then TrollTech with the current Qt prices. In this case Qt is a real alternative for commercial development and the Qt/KDE also more attractive platform for developers. 2004-03-25 11:18 am Novell should by trolltech not QT since QT is trolltech’s main product 2004-03-25 11:27 am “In this case Qt is a real alternative for commercial development ” >>>>>>>>>>>> A real alternative? Qt is already good in business and use for commercial development. Gtk+ which is LGPL had no such big success in commercial development. Thus I don’t see how LGPLing Qt would be a gain. Qt is already more sucessfull in comercial development than the LGPL GTK+. 2004-03-25 11:34 am As i understand, Novell doesn’t want to use the same Toolkit for every platform they support but instead use the “native” ones. Windows has SWF, Mac OS X has Cocoa… I still don’t see Novell really using QT but let’s say it will be QT on Linux. QT is GPL under Linux so there’s no problem here, they can use it without problems. They however don’t need it for Windows. Personally I like GNOME better but this could also be the one-time opportunity to get a merge done. I know this will be an incredible amount of work but as Novell seems to be doing it anyway… Taking the current KDE (which has a few pros architectural-wise), porting to MONO/QT# and making the Interface sane ala GNOME wouldn’t be a bad thing I guess. In the process it would be cool to drop all the “K”s in front of the application’s names because it’s somewhat frustrating and pointless if you have to read over the first character when you try to find an application 2004-03-25 11:39 am > The easiest in my opinion is Gtkmm. This means you never tried to make your own widget with gtkmm. QT is much better. All you need to do is derive QWidget and implement paintEvent. In Gtkmm, you must implement realize, expose, and other events with an arcane meaning, undocumented. Not to mention the incredible difficulty knowing the current size of your widget. 2004-03-25 11:41 am Until recently Qt# needed pnet (Portable.NET) to build. pnet is licenced under a modified GPL. Could this be the reason why Qt# was also GPL licenced? I dunno. 2004-03-25 11:45 am I may be absolutely wrong, but I think qt# is gpl because qt is gpl. 2004-03-25 12:07 pm To be honest, I haven’t spent much time with QT so I probably not fully aware of what it can do, however I know it is alot more powerful than gtkmm but then again QT has alot of money and backing behind it. I probably like gtkmm because it was the first C++ GUI toolkit I learnt after using gtk and C. 2004-03-25 12:26 pm If QT# would really be the default GUI toolkit for Mono then i don’t think that a lot of Windows developers will port their programs to Linux/Mono. Perhaps the big companies, but the small software companies will not pay for an expensive Trolltech license given that it is very uncertain that enough Linux users would buy their products. And if i would like to give my open source program a BSD license, is that possible if you use the GPL’ed QT#? 2004-03-25 12:44 pm Wouldn’t it depend on what the QT# developers call a derivative work? I mean, the Linux kernel and it’s include files are all GPL, but there is no license problem because Linus allows commercial applications to link to the Linux kernel. And doesn’t it also depend on the programming language? I mean, in C(++), you need to include header files to use a library, so that a piece of GPL code is actually inserted in your code. But in Pascal, you compile a unit first and then link a program to it. So then the question is: what method does Mono use, and what will the QT# developers call a derivative work, I think. When files are #included? Or when they are (dynamically) linked too? 2004-03-25 1:18 pm >A real alternative? Qt is already good in business and use >for commercial development. Gtk+ which is LGPL had no such >big success in commercial development. >Thus I don’t see how LGPLing Qt would be a gain. >Qt is already more sucessfull in comercial >development than the LGPL GTK+. IMHO the Qt with it’s price and features not comparable with microsoft visual studio .net 2k3. Yes it is not multiplatform, but far more then a simple widget set and dialog editor… The main opponent of the Qt system not the GTK+ but the Visual Studio, Borland Delphi and others. If you start a new commercial project you must decide the platform, development environment, etc. In this case IMHO the Qt with its price and features not too good solution. Especially true it is if your company and project is relative small. 2004-03-25 1:36 pm Well, that’s really not a problem, because there isn’t really space for small application vendors on Linux anyway. The type of $20-$30 shareware apps that these companies sell are pushed out of the market by open source software. There is a place for proprietory software on Linux, but the low end ain’t it. 2004-03-25 1:41 pm The is a _new_ non-commercial version of Qt for Windows with the recent Qt programming book. I can’t remember the name, but look for older news on osnews.com. 2004-03-25 1:47 pm >IMHO the Qt with it’s price and features not comparable with >microsoft visual studio .net 2k3. If this is true (and remember, you can use KDevelop as a IDE), then what do you think about the GTK devel tools for corporate use? They have even less features, support and are less stable. 2004-03-25 2:12 pm March 3rd, 2003 Ermmmmmmm 2004-03-25 2:23 pm > Wouldn’t it depend on what the QT# developers call a derivative work? No. The GPL isn’t dependent on derivative works, it’s dependent on linking. Merely linking to a GPL library requires that your code also be released under the GPL. Granted, the GPL was written in the age of C program linking, not dynamic run-time linking (.so files, Java files, C# files, Perl, Python, etc.), but this doesn’t actually change anything significantly. You depend upon the GPL library to operate, so you’re still operating under the GPL. The Linux kernel is a separate matter, as you’re not linking directly against the linux kernel. You don’t depend on the Linux kernel. Your program could (in principal) use the BSD kernel, or Darwin, or BeOS, or whatever; you’re not dependent upon Linux. Linus has explained this before. Finally, programming language doesn’t matter. If Qt# were LGPL, it could come into play — if you’re including LGPL code into your program (which a header file would do), you might need to follow the LGPL license. But this is subject to fair use. So just grabbing a header file for function prototypes doesn’t kill you, and small macros (“small” being defined by the library author, but typically < 10 lines) would be acceptable under fair use. C++ Templates are problematic, which is why (L)GPL isn’t good for modern C++ libraries (unless you provide an exception for template-generated code, which IIRC libstdc++ does). But this whole line of reasoning is moot, as Qt# is GPL. You must link against it Qt# to use Qt#, thus you must be GPL. No Ifs, Ands, or Buts. 2004-03-25 3:19 pm Actually, you can be BSD/MIT/X11/Artistic 2.0/etc as well. Any GPL-compatible license will do. 2004-03-25 3:32 pm If you want Qt for Windows, you can have a look at the KDE on Cygwin project. http://sourceforge.net/projects/kde-cygwin/ They’ve got Qt 3.2 available for download. I’ve never tried it so I can’t vouch for its quality. 2004-03-25 4:57 pm >> Well, that’s really not a problem, because there isn’t >> really space for small application vendors on Linux anyway. Right, but what about Windows and Mac OS X where shareware is quite common? 2004-03-25 5:08 pm > IMHO the Qt with it’s price and features not comparable with microsoft visual studio .net 2k3. > Yes it is not multiplatform, but far more then a simple widget set and dialog editor… And Qt is just a simple widget set and dialog editor?? You should really take a look at http://doc.trolltech.com. It’s feature set is more comparable with Java’s libraries (GUI + database + QTL + …) than a widget set. 2004-03-25 5:11 pm No. The GPL isn’t dependent on derivative works, it’s dependent on linking. Merely linking to a GPL library requires that your code also be released under the GPL. ————— I don’t know where you get that idea. The GPL doesn’t include the word “link” anywhere, but it has whole sections about derived works. 2004-03-25 7:02 pm No. The GPL isn’t dependent on derivative works, it’s dependent on linking. Merely linking to a GPL library requires that your code also be released under the GPL. No actually it’s the other way around. The GPL does not specify what license your libraries must be for linking against GPLed software, but it does specify that the GPL governs derivative works. You must link against it Qt# to use Qt#, thus you must be GPL. No Ifs, Ands, or Buts. Nope, that isn’t true. http://www.gnu.org/licenses/gpl-faq.html“ 2004-03-25 7:36 pm From the GNU License FAQ: If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL? Yes, because the program as it is actually run includes the library. — The GNU legalese is imho pretty complicated, but i think that means that any program that uses QT# has to have a GPL license. I guess that’s what some people call the viral aspect of the GPL. 2004-03-25 8:22 pm A program that links against a library is not a derivative work. To argue as such is to argue that any C program is a derivative work of the standard C library (printf(3), et. al). To be a derivative work, you need to actually derive something from the original work. Calling/invoking printf(3) isn’t a derivative work, but changing the implementation of printf(3) would generate a derivative work. Again, this is why user-space Linux programs don’t have to be GPL. By copyright law, they’re not derivative works, and thus the GPL doesn’t apply. Instead, linking against a GPL library instead creates a “work based on the Program” (in the GPL’s language), which must follow the same rules as derivative works under the GPL. “Linking” probably isn’t the clearest term, but it’s an effective term. The key principal is that everything that makes up a “program” must be distributable under the same license, where a program refers to (1) all libraries within a single address space, or (2) all programs that share data structures (in accordance with “What is the difference between “mere aggregation” and “combining two modules into one program”?”: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation). Even though the GPL doesn’t explicitly state “linking” anywhere, the behavior of the Unix process, and what it takes to load/execute that process, is key. Finally, the GPL only applies to distributions of the binary code. So, what’s all this mean? It means: (1) If you want to distribute binaries which link against a GPL library, your source code must be released under a license compatible with the GPL. BSD with no advertising, MIT/X11, Public Domain, and others all qualify. (2) This also means that you need to provide the source for all the GPL libraries you’re using in the binary, through some mechanism. So if you compile an app, statically link it against readline, and distribute the app, you must provide a way for your users to get the source to readline. NOT the source to the most recent readline; you need to provide the source to the same version of readline that you used. This generally works as a reason to not statically link against GPL libraries, as it increases the amount of work you need to do. Dynamic linking is fine, as you’re not distributing the dynamically-linked libraries. 🙂 See clause 3 of the GPL. (3) If you don’t distribute binaries (i.e. if you keep all your binaries within a single organization), the GPL doesn’t apply, so the license for your code doesn’t matter. (4) Similar in spirit to (3), if you only distribute source, you can use any license you want, even if it’s GPL in-compatible (Apache 1.x, BSD with Advertising, etc.). Of course, your users will need to compile locally, and they can’t distribute any binaries they create, but it should be perfectly fine for them to run such binaries. I must apologize for my earlier comment, as I was trying (unsuccessfully, apparently) to simplify things. Code you write which links against a GPL library doesn’t need to be GPL. It only needs to be GPL-compatible, but any distributed binaries must be distributed under the terms of the GPL. This requirement makes it impossible to write proprietary software using a GPL library, which (of course) was the purpose. This means that Qt# cannot be used in proprietary apps, though, which many people seem to consider as being a “bad” thing (and I’m inclined to agree). Finally, Re: David (No actually it’s the other way around. The GPL does not specify what license your libraries must be for linking against GPLed software, but it does specify that the GPL governs derivative works.), I think we’re talking about different “directions”. If the library is GPL, it places limitations on the resulting program, as described above. Your comment seems to be about the program being GPL, in which case (yes) the library can be under any GPL-compatible license, or even a proprietary license if the GPL program makes an exception for it. 2004-03-25 10:29 pm I think we’re talking about different “directions”. If the library is GPL, it places limitations on the resulting program, as described above. Your comment seems to be about the program being GPL, in which case (yes) the library can be under any GPL-compatible license, or even a proprietary license if the GPL program makes an exception for it. Yep, that sounds right. 2004-03-25 11:16 pm Chris Stone did not say anything about Qt, and most desktops at Brainshare are running SUSE Linux with the Ximian Desktop. There have been also about 10 sessions related to Mono and Gtk# 2004-03-26 5:56 am >If this is true (and remember, you can use KDevelop as >a IDE), then what do you think about the GTK devel tools >for corporate use? They have even less features, >support and are less stable. KDevelop is really good stuff, but it is not Qt but KDE tool (free software, not related to TrollTech) and you can develop Gtk, wxWidgets, Fox, etc. with KDevelop + gcc. And the other side also there is relative good GTK tools: Anjuta, Lazarus for free pascal, Monodevelop, etc. IMHO GTK and Qt also not too useable for business under linux, at this monent only the Kylix the one and only useable native developer tool under linux, plus the java stuffs (Netbeans, Borlad JBuilder). For special purpose (browser, office, etc) you can use GTK or QT but this tools are only a funny toys if you compared it the windows based developemnt environments, like visual studio for .net 2k3. It is not a problem if you see the GTK: it is free. But the price of Qt professional is higher then visual studo professional and IMHO it is not correct. 2004-03-26 6:22 am Given that Qt/X11 and Qt/Mac are GPL or QPL and the fact that Qt# is a necessarily a derivative work, there is not a lot of choice in the licensing for Qt#. I admit that my knowledge of the QPL is very limited, so I do not know if the QPL would be useful as an optional license. 2004-03-26 12:24 pm Anonymous: But I don’t think that they plan to buy Troll Tech and relicense Qt. I don’t see how this will make their profit bigger. Why do people fancy Novel as a kind of Robin Hood? Nothing could be further away from reality. 1) Novell, in the asquistition of TrollTech, would be able to control/influence the development of Qt to its own liking. That means, they depend less on the goodwill of TrollTech and partnership agreements and they are able to build long term plans. 2) In addition to that, with Qt free for all platforms, Novell could potentially make tools (i.e. a VS-liked IDE) that could be their money maker. In addition to that, more developers would be attracted to Qt as a platform because it is free, and its applications can run without much changes on three major platforms. Plus, if Novell’s integrates Mono into Qt, it would be a boon for Novell’s sales. Why? More developers and users alike would consider Novell’s offerings. 3) They would also ensure that Qt would become the de facto standard on Linux. Because they control both Mono and Qt, they can mould them together and present something that would attract a whole lot of developers. GTK? Probably would whither away. In all this, Novell is given a commanding position, owning both Trolltech and Ximian. 4) And what about the embedded market? Qt Embedded is in the lead in the Linux PDA market. If Novell considers going into that market, gaining Trolltech developers would be a Good Thing(TM). All this of course depends on how much Trolltech would be bought for. If it is $20-40 million bucks, I would say it is worth it. Just because Qt would automatically be licensed under the BSD license doesn’t mean Novell would loose out in any way. The aquired developers itself would be enough to justify such a purchase. 2004-03-26 2:06 pm Quothe Marcus Urban: Given that Qt/X11 and Qt/Mac are GPL or QPL and the fact that Qt# is a necessarily a derivative work, there is not a lot of choice in the licensing for Qt#. This is incorrect. A derivative work is a work that actually includes a part of the original work. Merely using the work doesn’t make you a derivative. You have top actually copy/change and include the original source to be a derivative. This is why the KDE libraries are LGPL, even though Qt is GPL. This is why IBM’s JFS filesystem can be GPL, even though it executes within AIX, possibly using some of the original Unix code, which was licensed from AT&T/Novell/SCO. This is why you can write proprietary or free/open-source software for Windows, using Microsoft’s proprietary libraries (user32.dll, gdi32.dll, etc.). There is no need for Qt# to be GPL. It’s creator just desires it to be GPL. That is all. 2004-03-28 7:31 pm Chris Stone did not say anything about Qt, and most desktops at Brainshare are running SUSE Linux with the Ximian Desktop. Er, yes he did. Yes, Ximian Desktop was used a lot at Brainshare, but that it is what has been primarily used up until now. Anyway, the point is that Ximian Desktop is still not installed by defult anywhere, not on Suse or on any distribution.