UICollection is a rich set of Java Swing widgets, solutions for common and not so common Swing projects, and a workflow using a graphics designer to merge all solutions into one project. The project contains font/color/file choosers, layout managers, a translation framework and action framework, plus many useful classes for general Swing programming, like a MainWindow. The unique one stop solution for all your Java client user interface needs with advanced widgets, proven design techiques, and excellent API documents.
Re: Qt pricing
> % Plus there's always Java ;-))).
> Java has its own set of issues,
> but it is certainly an interesting
> choice too, if you are ready to
> program in java. I think the most
> problematic things today is
> about the jvm and the version of java
> you are using may not
> be the same as your target, so you have
> to spend time
> adjusting things (I heard some java
> developers saying that
> they were "porting" their app to another
> jvm) but I may not
> be uptodate with such problems.
Java adds new features and widgets in new versions, it
also fixes bugs that could trigger bugs in the authors code.
It does about the best job in the industry to keep forward
compatible, though. Writing something for java 1.2 works
on 1.4. This is something that just about every other
toolkit forgot about. You still see Qt1 applications out
there, which are really hard to get compiling against a Qt3
library, many many changes are neeeded.
In short; it is no worse then Qt or other libraries out there,
and probably better.
The reason your friend was porting was probably that he
used a newer version and the management did not want to
upgrade the JVM, which has its own set of problems :)
Re: Qt pricing
> Java would probably work
> also, but I think you'd have to include
> the JVM with your app
> for legal and configuration reasons;
> that's substantially bigger
> than statically compiling Qt in, and the
> program would be
> much slower and use much more memory
Those claims are either simply not true; or have been
remedied in recent versions.
Profilings of a full gui application with netwerk
communucation and many other things discovered that the
client took only 5 Mb, while the library added another 6
Mb. If the Qt on linux numbers are anything like they are
on Windows, then Qt is larger then that.
The slow is mostly due to bad programming, since Swing
is easy to program badly. Guis that have been released
more recently have shown to be very responsive, in no
spall part due to the update in Java version 1.4.2 which
REALLY made things faster for swing.
Considering the legal reasons; it is fully legal to ship a
JVM with your application, as you said; but there are many
other ways of getting it. The best example is that all new
machines coming from Dell (and HP and probably others)
ship their machines which have an OS including the latest
On account of the RAD environment; QtDesigner spits out
XML, which the project http://freshmeat.net/projects/uic/
uses to create Swing code.
Disclaimer; I am the project mainainer of above project.