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.

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.

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.

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.

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.

> 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.
>
> martin
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.

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.

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.

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.

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.

Adrian

"Guillermo Castro" wrote in message
news:ahsd87$e1h$1@rogue.oti.com...
> Hi,
>
> I've been searching all around looking if someone is developing the
KDE-SWT
> binding. So far, I haven't found anything. KDE is not even mentioned on
the
> main SWT page as a future supported platform.
>
> Are there any plans to create this? If not, I would try to do it myself.
>
> Thanks,
>
> --
> 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 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)

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.

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.