Qt# 0.4 has been released! Qt# is a set of cross-platform C# bindings for Trolltech's Qt GUI toolkit that is currently targeted towards Mono and Portable.NET. Along with some initial API documentation, code samples, tutorials and bugfixes, there have been a lot of improvements over 0.3, including support for events, multiple custom slots, object tracking and even preliminary support for Microsoft.NET. Download here -- some screenshots can be found here [Ed: wow and wow], and Debian apt sources here. Interested parties should also feel free to drop by #qtcsharp on irc.OpenProjects.net.
would you please define ...
"PHP will be considerably harder once you start doing real world stuff."
Ugh, i really hope i wont have to read the code for any QT applications written in php, or even perl. Those languages tend to promote bad code. (as in, hard to read and maintain)
While i like perl and php i would never use them for gui apps.
Haskell promotes good code :)
KDE/Qt Bindings for Haskell, Haskell support in Guideon... that would be really nice.
What makes bad code are bad programmers ;)
Well documented code can even be bad that will work once anybody can "fix" it easily.
Anyway I like the possibility to write PHP code in some ways as it let's. So you can write code similar to Perl, C, C++, etc. Just choose and make it clean and well documented.
> What makes bad code are bad programmers ;-)
I agree. However, with other languages, ONLY bad programmers write bad code ;-)
There are literally thousands of Java applications out there that could usefully be ported to KDE. People's time would be much better spent supporting this route than fantasizing about cloning Dotnet - you really think MS is going to allow this to happen?
Java/KDE bindings *have* been created, but unlike most libraries these are licensed under the GPL. This is having a most unfortunate effect. Big name semi-commercial projects such as the IBM Eclipse IDE *do* want to support KDE/Qt (Eclipse uses its own UI library called SWT) but the GPL license prevents this, since Eclipse code also appears in commercial form in the WebSphere product line. So they continue with Gtk+ and KDE stays on the back-burner.
The result of this available-but-not-usable situation is that KDE is losing momentum in the key area of Java applications - the GPL libraries can only be used for the (generally small) GPL applications.
Of course it would be I'd be happy if IBM were to compensate the developer of the Java/KDE binding, I hope they or some other companies do. However, at the moment, the road ahead for Java on KDE is blocked and the 'workaround' of C# is fraught with danger.
Do you mean that the Java-bindings for Qt are GPL:d? Only GPL?
This clearly shows the problem with GPL:d libraries.
The use of the GPL (rather than LGPL) was no accident, therefore it is no more a 'problem with the GPL' than breaking the speed limit on the road is a problem with speed restriction signs.
You could well, you know, ask the author, instead of complaining on a website.
On the other hand: the Qt/Java bindings still may have some code from my old QtC, and that is ONLY available under the GPL, so remember to ask every copyright holder.
On the third hand, if IBM so wants to use Qt, they can relax the license on THEIR code.
After all, supposing I was the sole copyright holder (I don't even know if I am one), what has IBM done for me lately?
As it apparently wasn't obvious from my post, the author *has* already been contacted by IBM and currently is not willing to change the license. As I have said, I have no quarrel with the author - good luck to him/her/them in getting a return on their investment. It's the effect on the rest of us that's the problem.
I'm afraid I'm not in a position to speculate what IBM might or might not have done for the author(s) concerned. However, IBM has contributed very significantly to Linux and open source - overall I guess some give and take would be reasonable.
Uh, you do know that the person you are replying to is the original author of the QtC bindings that both qtjava and Qt# rely upon. Richard Dale extended these bindings and created qtjava. I do not think Richard would have a problem relicensing his code under LGPL or X11. I don't presume to speak for Roberto.
You should also know that Qt# is licensed under the GPL, so we have the same problems with commercial applications as the other bindings. We are working to change this and as long as the Trolls agree we'll be able to develop cross-platform apps with Qt#. Of course even if Qt# were LGPL or similar license, a commercial developer wishing to link to Qt# (and thereby Qt/C++) would still need purchase a license from Trolltech.
Just to clarify, as far as I am concerned, Richard Dale is the one who deserves all the credit, and whatever he says goes.
If he was contacted and refused, he must have his reasons. I am sure IBM could convince him if they really wanted.
But what is the point? To do proprietary apps, you still need to buy Qt.
I suppose dual-licensing under GPL/QPL would be better, since it allows use of other licenses beyond the GPL. If Richard agrees, of course, but I am not in the business of convincing people.
If there's some special significance in the previous statement about Qt/Java from Roberto then please feel free to enlighten me, meanwhile either you or the Eclipse contributors appear to have misunderstood Richard Dale's position.
Here is the discussion from the IBM Eclipse list - if a way forward can be worked out that would be very welcome news.
From: David Goodenough
Subject: Re: KDE SWT binding?
Date: Thu, 01 Aug 2002 11:46:01 +0100
Organization: D.G.A. Ltd
NNTP-Posting-Date: Thu, 1 Aug 2002 10:42:43 +0000 (UTC)
Martin Möbius wrote:
> Guillermo Castro wrote:
>> So it's a licensing issue, then...
>> I don't understand much of the licensing restrictions. I know SWT is
>> under the CPL, and QT is GPL. KDE/Java binding is also GPL. Is the CPL a
>> more restrictive license? where/who can clarify what would be needed to
>> make eclipse run as a 'native-looking' kde app?
> Perhaps contact the author of the kde/java bindings. I assume licences can
> be changed by the author, but I do no really know.
I have already done so. He is unwilling to change the license because he
is in the business of making money from writing JNI bindings and does not
want to release these ones under LGPL to match the KDE libraries. I
suppose if someone were to dangle some money under his nose he might.
OK, then. He doesn't want to change it.
IBM can relicense eclipse just as easily as he can relicense his code.
Anyway: the licensing on Qt bindings is tricky.
The binding-generating tool is GPL.
But what about the generated code? The generated code is a derived work of Qt, probably, since they are generated from Qt headers.
As such, I don't know if Richard can change the license of that code, which may be under a dual QPL/GPL license.
IBM should ask a lawyer and/or pay Richard.
How do you know that they actually want to support KDE? I find that most/all commercial companies just don't care about Qt/KDE, they all go with Gtk, which is a shame. If IBM really wanted to support KDE they probably could, but the serious will to do it is probably not there.
Hmmm... which commercial companies are all going with GTK????
But then again, TheKompany goes with Qt.
Gobe productive, a really great, fast, feature complete office suite is also gtk based, as is the official Yahoo instant messanger, loki games (mainly the loki installer, which will hopefully live on even now loki's dead) netscape also uses gtk(internally), and i guess even Mandrakes setup tools could be considered in this category (they're gtk, and last time i looked they weren't gpl) Openoffice is also shifting to using gnome's accessablity toolkit (but not gtk).(IBMs eclipse was also mentioned above) - So, lots (relatively).
However i've also found that quite a few commercial apps still use Motif (or something that looks just as bad) examples of this are Codewarrior (which is an otherwise great IDE) realplayer, and acrobat reader.
There are a lot of Qt based stuff. Hancom Office is Qt based.
Look at trolltechs homepage. There are a lot of applications
which require a strong solid base that use Qt. Mainly, the
apps I've seen for gtk are smaller. Qt is the best base to build
a larger project upon. Of course, for a smaller app (yahoo messenger)
it might not be worth the price, but in the long run Qt is excellent.
And then again, nothing stops you from using gtk-apps in KDE.
My impression though, is that gtk is more a toy while qt is professional.
That's like saying Linux/*BSD are toys and that Windows/Solaris/CommercialUnix are professional.
OK, GTK+ isn't C++, but it's a very, *very* nice C-based object oriented (!) GUI tookit.
> GTK+ isn't C++, but it's a very, *very* nice C-based object oriented (!) GUI tookit.
Programming GUIs in C is like being mauled by a hippopotamus.
Doing it using GTK+ is like being mauled by a nice hippopotamus.
> Programming GUIs in C is like being mauled by a hippopotamus
> Doing it using GTK+ is like being mauled by a nice hippopotamus
Is there even a point, now when we have Qt?
Yup, Gtk definatly has it's uses. It's nice in small situations (like loki's installer), when you need the library statically linked.
Also, when you need to develop propreitary software and are unwilling to pay for a properitary-usage copy of Qt.
Good question, particularly as the earlier posting I quoted was not from an IBM person. However, Adrian Cho is at Object Technology International, owned by IBM and the source of Visual Age, and below is a response from him. They're interested, but are "caught" by both Java/KDE and Qt licensing.
From: "Adrian Cho"
Subject: Re: KDE SWT binding?
Date: Mon, 29 Jul 2002 11:34:41 -0400
Organization: Object Technology International, Inc.
NNTP-Posting-Date: Mon, 29 Jul 2002 15:33:39 +0000 (UTC)
Are you talking about KDE or Qt? The OTI/IBM team has an initial port of
SWT Qt but it will not be released until we complete further investigation
of the legal issues due to licensing incompatibilities.
GTK+ is under LGPL and hence the SWT GTK+ binding is LGPL'ed. Qt however is
under the QPL and this license is problematic for us.
"Guillermo Castro" wrote in message
> I've been searching all around looking if someone is developing the
> binding. So far, I haven't found anything. KDE is not even mentioned on
> main SWT page as a future supported platform.
> Are there any plans to create this? If not, I would try to do it myself.
> Guillermo Castro
> Java Developer
So, the problem is not with Richard's bindings being under the GPL, but with Qt being under the QPL?
The QPL doesn't forbid much in the way of usage, as long as the code using the QPLd code is under a free license. The big exception is that the GPL collides with pretty much any other license (never legally tested, just the FSF claims).
So, as an exception, Qt is also available under the GPL for that reason.
Perhaps, as usual, the situation would be clearer if those actually doing the stuff talk to each other.
Does this SWT binding link to Qt? I guess yes.
Does it link to other code owned by IBM? I guess yes.
Now, the only reason why there can be a legal prolem are:
a) The binding license is incompatible with the QPL (in other words, it is not free)
b) The other IBM code has a restrictive license that is incompatible with the QPL (ie: THAT code is not free)
In no case is the restriction being imposed by Qt's license, but by the other code's.
If IBM intends it to be free software, or open source software, they probably CAN do it.
If they don't, probably they can't.
But without knowing the code and the licenses involved, it is silly to efven guess.
From all the posts, I haven't found anyone trying to come up with a solution. I think java developers would benefit from a java/kde binding. If the current binding has a restrictive licence, why not create a new binding with a less restricting licence, like LGPL? It has been done before, you know, and that's the beauty of OSS.
To quote: "Java support for KDE is now fairly significant, you can add applet support to your KDE applications, and with the Qt/KDE Java bindings you can even develop KDE apps in Java. Issues relating to Java support for KDE should be discussed on the kde-java mailing list (though applet issues are usually discussed on kfm-devel)".
I think you misunderstood me.
I know there are Java Bindings for QT/KDE, but the problem is that those are under a license that doesn't allow the Eclipse team to create a SWT-KDE port. Since the binding's author doesn't want to change the license terms, there are two options now for Eclipse:
1.- Avoid porting SWT to KDE, and use GNOME and Motif for linux (which is what they're doing right now)
2.- Create a Java-KDE Binding from scratch (or let someone else do it).
Since they're happy with 1 and we can't change the license, we won't see eclipse running on KDE unless we create our own binding.
I hope I made myself clear now...
the samples seem to indicate code written in Kate - does or will a developer have the ability to develop programs in the KDevelop and Designer ide using the qt# language?
no. not at this point anyway...
a number of people have brought up the idea of integrating uic/designer with Qt# on our IRC channel. if you would like to see this then I suggest you talk with marcus on #qtcsharp or the list...
Adam, can you get Qt# integrated as a main component into the Mono distribution?
It is possible, but we'll have to eliminate the dependency upon libqtc first... I don't know what advantages there would be in hosting cvs under mono though. That is what you mean isn't it?
I want them to promote Qt# as part of the Mono project just as much as they are promoting GTK#. Why do you have to eliminate the dependency on libqtc?
Ximian is not in the business of developing for the KDE Desktop. They have sponsored and founded the Mono project, so wishing that they would promote Qt# as much as Gtk# is a only going to lead to frustration. They have been very gracious with there time and attention to all the questions and problems we have faced with Qt#.
It has been a wonderful experience working side by side with the Ximian/Gnome developers and I wish to emphasize the positive instead of dwelling upon the differences. Besides, Qt# should work equally well with Portable.Net as well as Mono.
Now, the dependency upon libqtc is a nasty one, because it prevents us from becoming a truly cross-platform lib. libqtc is licensed under the GPL which disallows linking to any other version of Qt besides Qt/X11. It is also very difficult to maintain. Hope this clears the air a bit.
What is libqtc exactly and why is it needed? Qt is GPL in the first place...
libqtc is a C binding for Qt.
The idea is that languages link easier to C libraries than C++ ones, so libqtc works
as a C buffer, and you link language->C->C++
I don't much see how C# is going to link to C++ classes without it or something similar, though, but I know nothing about C# ;-)
This approach is the same used by Kylix, too.
Although Qt is GPL, Qt is not ONLY GPL.
Qt is also under the QPL, and under a commercial license, and under a free-as-beer-sometimes license.
Since qtc is GPL, you can not use it with a Qt licensed under any of the other licenses.
Here`s an idea. If IBM or Ximian or whoever pays me 2500 U$S, I promise to write a new QtC under a BSD license.
Many better programmers can do a better job, but not many can do it cheaper or claim to have done it before ;-)
A small question. Is there a possibility to develop closed source
freeware programs with Qt? Shareware (what's the difference anyway)?
Of course you can.
It's gonna cost you, though.
I guess that's the philosophy here.
If you use open source, you support open source.
Although that has nothing to do with Qt, small closed-source shareware/freeware projects seem to be a waste of time in >90% of cases. The mentioned >90% of them die, and there's almost no benefit to the society (nor to the original programmers). For small projects that are meant to stay small, open source (ideally GPL) is almost always a good way to proceed.
AFAIK, there are only a few relatively small "shareware" type projects that have stayed in the marketplace for a longer time and had generated useful revenue. WinZip comes to mind.
There have been a beautiful shareware utilities for DOS, some of them quite worth porting to unix nowadays. Yet they have been a waste of time from *today's* perspective since there's no easy way to reuse and expand them, even if we forget about licensing problems. Even though the utilities were useful and all, they are now in bit-heaven. The companies that did them don't exist, some of the programmers that did them may have even retired or became air traffic controllers by now. And I doubt that most of these small shareware shops had short-livedness, or temporary benefit, as one of their goal. I do understand that some shareware authors might have done shareware to temporarily repair their home budgets, but that's a tiny percentage of all shareware makers.
To summarize: if it's a small freeware project, there's no point in not making it opensource: freeware doesn't generate revenue. And you can always make the project double-licensed, so that all outside contributors know that their code may be used in a commercial way. After all, what is the other point of keeping freeware closed-source? The only imaginable point is to make it sell for money, and that's where double-licensing works perfectly.
If it's a shareware project, the question is whether shareware is something you want to do. Yet, in many cases shareware can work anyway all right with open source and generate same or even greater revenue that it would without being open source.