• Back to all articles

GUI Toolkits for The X Window System

Offff, Why do i have to fill this ?
Yes Xlib is hell, But the apps. are damn vert lightweight.
I was writing an application, And i needed to add a keyboard layout selector.
This was the only case I had to use pure Xlib calls "not to mention my
dockapps"
For me, As a GNU/Linux user, I don't care about win32 or the portability issues
with win32.
I think that Gtk+ is the only choise for C lovers like me ;)

gtk rules
True true, Xlib is a royal pain in the ass, but it's quite fun and intresting if you have nothing else to do. I highly recommend GTK+ (simple, easy to learn, pretty, lots of documentation, etc.). Anyone who is intrested in some serious GUI development should try it!

Re: Offff, Why do i have to fill this ?
I would have to agree 100%.
Gtk+ really is a C lovers GUI Toolkit, and a very easy API to learn. If you are a C programmer, then applying the Gtk+ API to your application is nearly trivial.

I do wish however, that there were an easier abstration layer to Xlib in Gtk+, for instance, to change resolution and other core Xlib features.

> Yes Xlib is hell, But the apps. are damn
> vert lightweight.
> I was writing an application, And i
> needed to add a keyboard layout
> selector.
> This was the only case I had to use pure
> Xlib calls "not to mention my
> dockapps"
> For me, As a GNU/Linux user, I don't
> care about win32 or the portability
> issues
> with win32.
> I think that Gtk+ is the only choise for
> C lovers like me ;)
>

Re: gtk rules

> lots of documentation, etc.).

I can agree that there are lots of docs, But for low level aspects of Gtk/Glib I was really disappointed to discover that there is No docs, Or description for the API in the reference manual.

Nothing about Pango, Only the reference manual.

Re: Offff, Why do i have to fill this ?
That's not a very good programming practise. Remember that Windows is the most used OS out there.

> For me, As a GNU/Linux user, I don't
> care about win32 or the portability
> issues
> with win32.

Re: Offff, Why do i have to fill this ?

> That's not a very good programming
> practise. Remember that Windows is the
> most used OS out there.
>
> % For me, As a GNU/Linux user, I don't
> % care about win32 or the portability
> % issues
> % with win32.
>
>
>

Win32 does just about nothing to be compatible with other OS's. It's not meant to acknowledge the existance of any other OS's besides microsoft's. As a programmer you always want to stay away from external library dependencies as much as possible, but you shouldn't go completely out of your way, and possibly scope of your program, to maintain compatibility with an OS that's such a pita to develop on. You program what you use, let other people worry about porting it to what they use if it's not something you do.

that said, gtk+ is a great beginners api to learn gui programming on, in C and C++ programs. My only issue with toolkits like gtk+ and qt is that they're nice and snappy when they're plain, but add pixmaps to the picture and all of a sudden they're crawling compared to before. Even with all the xaa optimizations to pixmaps and window handling... I'm not sure which is at fault, x11 or the toolkit, or neither

xforms
The xforms license was changed to LGPL or so.

Re: Offff, Why do i have to fill this ?

> That's not a very good programming
> practise. Remember that Windows is the
> most used OS out there.
>
> % For me, As a GNU/Linux user, I don't
> % care about win32 or the portability
> % issues
> % with win32.
>
>
>

I totally agree but,
Even if it's the most use OS, I'm not using it, I believe that more apps = life
for the OS.
Why shall I increase the popularity of windows ?

Re: Offff, Why do i have to fill this ?

>
> % That's not a very good programming
> % practise. Remember that Windows is
> the
> % most used OS out there.
> %
> % % For me, As a GNU/Linux user, I
> don't
> % % care about win32 or the portability
> % % issues
> % % with win32.
> %
> %
> %
>
>
>
>
> Win32 does just about nothing to be
> compatible with other OS's. It's not
> meant to acknowledge the existance of
> any other OS's besides microsoft's. As
> a programmer you always want to stay
> away from external library dependencies
> as much as possible, but you shouldn't
> go completely out of your way, and
> possibly scope of your program, to
> maintain compatibility with an OS that's
> such a pita to develop on. You program
> what you use, let other people worry
> about porting it to what they use if
> it's not something you do.
>
> that said, gtk+ is a great beginners api
> to learn gui programming on, in C and
> C++ programs. My only issue with
> toolkits like gtk+ and qt is that
> they're nice and snappy when they're
> plain, but add pixmaps to the picture
> and all of a sudden they're crawling
> compared to before. Even with all the
> xaa optimizations to pixmaps and window
> handling... I'm not sure which is at
> fault, x11 or the toolkit, or neither

What i do is stick to POSIX, Yes windows may be important, But why do I have to buy a license just to port my GPL'ed app. ?
Isn't donating this money to the FSF better ?

I use the Mandrake galaxy theme under Debian woody
Say no to pixmaos ;-)

Re: Offff, Why do i have to fill this ?
I don't use Windows either, however, one of the reasons to code (at least me) is so other people can use the software has well, therefore I like to make it available for my non UNIX friends :)

>
> % That's not a very good programming
> % practise. Remember that Windows is
> the
> % most used OS out there.
> %
> % % For me, As a GNU/Linux user, I
> don't
> % % care about win32 or the portability
> % % issues
> % % with win32.
> %
> %
> %
>
>
> I totally agree but,
> Even if it's the most use OS, I'm not
> using it, I believe that more apps =
> life
> for the OS.
> Why shall I increase the popularity of
> windows ?
>

Re: Offff, Why do i have to fill this ?

> I don't use Windows either, however, one
> of the reasons to code (at least me) is
> so other people can use the software has
> well, therefore I like to make it
> available for my non UNIX friends :)
>
>

My non UNIX friends only care about: games, mp3z, movies "All types ;-)", chatting and sending me SPAM.

XUL?
Why is XUL not mentioned in this article?

QT rules
It is true that the QT library is very huge, but it offers a whole programming universe. QT is now freely availabe for Mac OS X to if the app is releases under the terms of the GPL. In addition QT is available for embedded linux too. It exists an older version for non-commercial, open source apps under win32 (no QT source).

Another advantage is that QT is developed very fast, for example QT has unicode support since 1999, other toolkits like GTK+ required more time (AFAIK since 2002 has GTK+ unicode support too).

The meta object compiler provides a C++ extension called signal and slot mechanism, which is typesafe. You can write each software component (classs) for its own and connect them without knowing each other.

Last but not least QT is developed by a business oriented company, but this doesn't matter because Trolltech needs money in order to develop such a great toolkit.

Tcl/Tk

The author wrote: Tcl/Tk isn't much better [than xlib]

That's complete nonsense. Tcl/Tk is just about the simplest-to-use toolkit there is, and it's cross-platform. True, on UNIX, Tk looks kind of old-fashioned and Motif-like, but I guarantee I can prototype a GUI in Tcl/Tk in about a tenth the time it would take with any of the other toolkits.

fundamental errors with QT
Trolltech made 3 fundamental errors with QT.

(1) Orginally releasing QT under a non-free license
Numerous license issues with KDE GPL software being incompatible with the orginal QT license. Many of the OSS community disapproved of Trolltechs license, which eventually spawned the Gnome project. Some people (like myself) still see Trolltech as just another money making business, rather than being truely part of the OSS community.

(2) Releasing it under a Dual license QPL, GPL.
Why not license a "library" under the LGPL? or BSD? Obviously it was there strategy on the Windows platform side of things, keep it closed and make more money off it.

(3) Ignoring OSS on any platform other than *nix.
They want huge profits, unlike other toolkits.. most are completely free (Motif?) Regardless of platform. OSS developers should embrace more open toolkits that actually promote harmony among other platforms and work/develop with community input, rather than companies trying to profit off it.

Trolltech are more interested in profits than benefiting the general OSS community, by not supporting a multi-platform toolkit they're disadvantaging themselves, and discouraging a broad user-base over different operating systems. OSS happens not just on Linux, but a number of operating systems, OSX, *BSD, Windows, OS/2, BeOS etc...

Someone should remind Trolltech.
OSS *is* Operating System Independant

ps. I'd be very surprised if dot.kde.org would publish this FM story, so one-sided some KDE related websites, anything anti-KDE/QT would be ignored,removed and banned.

Re: fundamental errors with QT

> ... most are completely free
> (Motif?) Regardless of platform. OSS
> developers should embrace more open
> toolkits that actually promote harmony
> among other platforms and work/develop
> with community input, rather than
> companies trying to profit off it.

Motif is completely free? Read http://www.opengroup.org/openmotif/faq.html (http://www.opengroup.org/openmotif/faq.html), the third item down.

Motif has been a disaster of a toolkit for most of its life. Its success has only been because of the lack of anything like it for about a decade. I lament that so much needless work needed to be sunk into lesstif.

The sooner Motif dies, the better. A poorer example of an open source project would be hard to find.

Re: Tcl/Tk

> ... I guarantee I can prototype a GUI in
> Tcl/Tk in about a tenth the time it
> would take with any of the other
> toolkits.
>

No way. GTK and Qt with RAD are every bit as fast, and the end result doesn't look like complete garbage when you're done. Every Tk app ever written looks like it comes from the bad old days of early 90s Unix, complete with disastrously ugly widgets, poor support for basic interaction things like focus control, clipboard, drag&drop, etc.

I suggest you take another look at GTK or Qt. They've come a long way.

QT as GPL
If QT/X11 can be used as GNU GPL there's nothing that prevents people from porting the X11 version to Windows, so in theory it would be possible for the OSS community to provide port of QT/X11 for Windows and other platforms.. that should be perfectly within the rights granted by GPL :)

Anyone considered such a project?

Re: Tcl/Tk

> No way. GTK and Qt with RAD are every
> bit as fast, and the end result doesn't
> look like complete garbage when you're
> done.

Maybe they are as fast, but Tcl/Tk is much more than just a GUI toolkit. It's a high-level scripting language offering many other things beside GUI programming (yes, Qt also offers much more, but I find it's not as beautiful and fun to work with as Tcl/Tk).

> Every Tk app ever written looks
> like it comes from the bad old days of
> early 90s Unix, complete with
> disastrously ugly widgets, poor support
> for basic interaction things like focus
> control, clipboard, drag&drop, etc.

In my experience, Tcl/Tk programs are among the most easily and most intuitively usable programs to work with. I also tried my best when writing my own Tcl/Tk apps. May I recommend that you have a look at Tickletankle and/or Alana (available on Freshmeat) and please tell me what annoys you.

> I suggest you take another look at GTK
> or Qt. They've come a long way.

Yes, maybe I should do this (have a look at Spakes, available on Freshmeat, written using Qt, and tell me what I can do better). Then again, maybe you should have a look at Tcl/Tk in turn.

Some things not mentioned about FLTK...
First, the current 1.x release of FLTK is portable to all systems using X11 and has "native" support for Windows and OSX, too. The whole low-level interface to the window system is abstracted via a very thin layer within FLTK, which means that you can easily port it to other environments (there is a version of FLTK for many of the Linux-based PDAs, for example.) The 2.0 release of FLTK (currently in development) will actually have separate modules (a la GDK in the GTK+ world) that implement the device class for various interfaces - X11, Quartz, WIN32, any of several framebuffer APIs, etc.

Second, there is a version of FLTK 1.1.x that uses UTF-8 for input and display of Unicode; this will also be part of 2.0.

Re: fundamental errors with QT
Well, releasing QT under the GPL is bad only if
you intend to sell your application without the
source code.

I think the GPL license is more suitable to
free software than BSD or LGPL.


> Trolltech made 3 fundamental errors with
> QT.
>
> (1) Orginally releasing QT under a
> non-free license
> Numerous license issues with KDE GPL
> software being incompatible with the
> orginal QT license. Many of the OSS
> community disapproved of Trolltechs
> license, which eventually spawned the
> Gnome project. Some people (like myself)
> still see Trolltech as just another
> money making business, rather than being
> truely part of the OSS community.
>
> (2) Releasing it under a Dual license
> QPL, GPL.
> Why not license a "library" under the
> LGPL? or BSD? Obviously it was there
> strategy on the Windows platform side of
> things, keep it closed and make more
> money off it.
>
> (3) Ignoring OSS on any platform other
> than *nix.
> They want huge profits, unlike other
> toolkits.. most are completely free
> (Motif?) Regardless of platform. OSS
> developers should embrace more open
> toolkits that actually promote harmony
> among other platforms and work/develop
> with community input, rather than
> companies trying to profit off it.
>
> Trolltech are more interested in profits
> than benefiting the general OSS
> community, by not supporting a
> multi-platform toolkit they're
> disadvantaging themselves, and
> discouraging a broad user-base over
> different operating systems. OSS happens
> not just on Linux, but a number of
> operating systems, OSX, *BSD, Windows,
> OS/2, BeOS etc...
>
> Someone should remind Trolltech.
> OSS *is* Operating System Independant
>
>
> ps. I'd be very surprised if dot.kde.org
> would publish this FM story, so
> one-sided some KDE related websites,
> anything anti-KDE/QT would be
> ignored,removed and banned.
>

Re: Tcl/Tk

%
> Then again, maybe you should
> have a look at Tcl/Tk in turn.
>

You're right. Can you think of a good example of a Tcl/Tk app that I should look at?

Re: QT as GPL

> Anyone considered such a project?

Such a project is already underway - check out KDE dot
news

Re: fundamental errors with QT

> (2) Releasing it under a Dual license
> QPL, GPL.
> Why not license a "library" under the
> LGPL? or BSD? Obviously it was there
> strategy on the Windows platform side of
> things, keep it closed and make more
> money off it.

Oooh, how *dare* they, trying to make money off
their library...

This encourages people to do one of two things -
port the GPL version themselves (as is happening), or
use the free version on a free OS. GPL instead of
LGPL/BSD was also a very good decision, which protects
TT's IP, while bolstering the open-source community.

Gtk+ and Gtkmm are GNU LGPL
As far as I know both toolkits are LGPL not GPL, and this is a crucial difference for users and enterprises willing to adopt and evolve to free software development from propietary business models.

wxWindows Theming and Qt Licensing
Actually, wxWindows does support theming. On *nix systems, it can use GTK+ as a backend, and GTK+ is fully themable. The wxUniversal port provides its own widgets, which are also themable. wxMotif is the only version I know isn't themable at all, even the MS Windows port is themable so some extent (namely through various skinning programs for Windows).

Now for something completely different: Qt under GPL. I think Trolltech was justified in their concerns about releasing under GPL. IANAL, but I think the GPL has two properties that enable one to legally write non-GPLed software with the Free version of Qt.

Fisrt, the GPL explicitly forbids putting further restrictions on distribution and use, including Qt's demand that the Free version only be used for developing Free software. As it stands, the Qt code becomes part of the final product, thus requiring that product to be GPLed. However, Qt may be modified so that this is no longer the case (i.e. thelibrary and the application become completely separated).

Secondly, the GPL requires a larger work to be released under GPL if and only if that larger work is distributed at all. This means that one could perfectly legally develop a larger work for use in-house without releasing a bit of source code.

This is not to say that I advocate punishing Trolltech for doing something that has greatly benefitted the OSS community and themselves alike. I am just sharing my thoughts, and hoping someone can enlighten me.

lol ?
First we should limit the number of toolkits to these, which are default avaible at every normal desktop linux distrybution.
Afaik there only 2, gtk+ ( NO GTKMM) and QT.

Ok then to qt

nice, but the license sucks.

GTK+
LGPL, ok, but looks ugly and GUI programming in
Assembler is over.
Portability ? Nope, the win32 Port was a one man show.
OOP with C, RUNTIME typechecking lol ?.
Modules are nice but, in 99% of the cases, the modules aren`t installed on the default linux distribution.
And gtk is only a raw toolkit, not a Appframework.
And then u call this RAD ?
A gui designer doesnt count for me as the only thing u need for RAD.

Re: Tcl/Tk

> You're right. Can you think of a good
> example of a Tcl/Tk app that I should
> look at?

As I said, I would like you to have a look at two of my own programs written using Tcl/Tk, namely "Tickletankle" and "Alana" (available on Freshmeat) and I'm looking forward to hearing your oppinion about them. (Please note that the dialog system in Alana needs some minor refinements which will be included in the next release. If you want, I can send you my latest local version, which already incorporates them.)

I also wrote an application using Qt: "Spakes". Please look at it too, and tell me what you think about it or what I can do better by using the more advanced tools that nowadays come with Qt.

Re: Tcl/Tk

> True, on UNIX, Tk looks kind of
> old-fashioned and Motif-like, but I
> guarantee I can prototype a GUI in
> Tcl/Tk in about a tenth the time it
> would take with any of the other
> toolkits.

If like the Tk programming but not its look, you should probably try gnocl which are GTK bindings for Tcl, modeled loosely after Tk.

Another set of opinions
Pretty good summary overall, although I feel compelled to
point out a few things I've noticed about the toolkits and
have heard from others:

- Qt is by most accounts the best designed, fullest featured,
and fastest to work with C++ GUI toolkit out there. The
licensing is a problem if you're porting Free Software to
Windows, but for commercial development the licensing fee is
usually justified by the savings in development time. It is also
the toolkit that comes on the Sharp Zaurus PDAs, which
makes it the only practical choice for that environment. It
doesn't use true native widgets on Windows and maybe
MacOS X (although it looks pretty damn close), which is a
problem for some people but also gives it some advantages
(see below about Unicode support).

- wxWindows is probably the next best choice for many
projects; if your feature and schedule requirements don't
demand Qt (or your portability requirements exclude it), give
this a try instead. Personally I'd like to see wxWindows
surpass Qt in quality, but I don't think it's quite there yet;
I would definitely like to see more people using and working
on this, though. It uses native widgets on all platforms,
which is a plus for some people but also complicates Unicode
support (see below).

- gtkmm has probably improved greatly since the release of
GTK+ 2, but the last time I looked at it (a while ago) there
weren't enough people maintaining it and the API seemed
fairly ugly. I'm hoping much of this has been fixed, but
portability to other platforms is still pretty much
non-existent.

Haven't used the others so I can't really contribute anything
regarding those. One thing that I don't think was really
emphasized enough was internationalization support; if you
need to use your program for anything but western European
languages on multiple platforms, your options get kind of
narrow:

- Qt just works for Unicode text manipulation and display on
all platforms it runs on, which in my opinion is one of its
strongest assets.

- wxWindows usually has Unicode support; before GTK+ 2,
the situation here was much worse. Unicode is barely
supported under Windows 9x, though, which is a serious
problem for much software. The basic problem here is that it
uses native widgets, and the older Windows versions didn't
support Unicode text display in the native widget set; you
have to install a Unicode support library which is apparently
buggy and incomplete compared to the NT/2000/XP Unicode
support (and will never get fixed, since Microsoft is dropping
support for those versions). Qt got around this problem by
rendering all of its own widgets.

gtkmm now supports Unicode, but it really only runs on
Linux/UNIX. Can't say much about the others, although it
sounds like most of them fare at best as well as wxWindows
on this.

Hope this is of use to somebody,

Jeremy

Re: Another set of opinions
% - Qt is by most accounts the best designed, fullest
featured, and fastest to work with C++ GUI toolkit
> out there.

> The licensing is a problem if you're porting
> Free Software to Windows

It is possible to port Free Software to windows using Qt
without buying a full commercial license. You must use the
cygwin version (http://kde-cygwin.sf.net). There is also a
project to allow a KDE application to run without Qt, on
windows: http://www.iidea.pl/~js/qkw/

The author mention that you must pay for a licencse to port
your program. He overlooks the fact that Qt is already
available for 3 platforms under the GPL:

- unix/X11

- MacOsX (X11 and native)

- embedded platforms like the Zaurus

Note that the embedded version of Qt can be used to run on
the linux framebuffer (http://dot.kde.org/1058619204/)

On windows, for close source development, you can also get a
license of PyQt which is 5x cheaper
(http://www.riverbankcomputing.co.uk/pyqt/buy.php).

> It doesn't use true native widgets on Windows and maybe
> MacOS X (although it looks pretty damn close), which is a

Qt uses native widgets on Windows XP. Latest Qt uses native
widgets on MacOs/X. For other platforms, the look is
emulated.

If I look at the so-called weaknesses of Qt, I find the article
biased against it:

1. Very business-oriented main Web site

Sorry, but I don't see how it relates to the quality of the
toolkit. I find the Gtk's site ugly as hell but I would not
mention that as a _weakness_ of Gtk. It does not relate to
the toolkit.

2. Main branch depending on one company

So what ? Qt is GPL, you can fork it any time you want. Given
that Qt is the income source of Trolltech, I don't see
how they would not develop it. Is it a problem that MySQL
develops MySQL ? Really, I don't see the point of this remark.

3. Commercial developers and people wanting portability have
to pay.

See my previous remark on the various alternative options.

4. Huge sources and binaries, library itself takes ages to
compile

He, that one is true. Qt4 will be separated in multiple
components, but I don't think it will be out before a few
years. Qt3 is still very good.

5. Objects not referred by namespace but simple literal prefix
"Q"

So ? Apart from a matter of taste, I don't see any problem
here. Gtk object begin with G (or is it gkt_ ?) and what is the
point ? Q is shorter to type than 'using namespace Qt;' . I
personally never had any naming conflict with Qt. I would put
that together with the uic: it is only a problem for C++
purists.

Re: lol ?
% Ok then to qt
>
> nice, but the license sucks.

I find this a too quickly rebuttal. Why does the GPL sucks
exactly ?

Oh, or you mean you can not write proprietary application
with it. The author of the article seem to have the same
opinion, that you should be able to write proprietary (==
close source) application at no cost with a toolkit, else it is not
a good Free Software toolkit.

I fail to see the connection though. I thought freshmeat was a
site on Free Software development, I was not aware that it
had turned into a close source promotion site.

Re: Gtk+ and Gtkmm are GNU LGPL

> As far as I know both toolkits are LGPL
> not GPL, and this is a crucial
> difference for users and enterprises
> willing to adopt and evolve to free
> software development from propietary
> business models.
>

Yes, those enterprise can get all the benefit and advantages
of Free Software, but continue to develop close source
software without paying any cent to the developer that made
their tools (Gtk, ...)

I prefer the model where you can do Free Software for free
but have to reward those that give their work to you when
you are using them to make money (Qt)

Re: fundamental errors with QT

> Trolltech made 3 fundamental errors with
> QT.
>
> (1) Orginally releasing QT under a
> non-free license
> Numerous license issues with KDE GPL
> software being incompatible with the
> orginal QT license. Many of the OSS
> community disapproved of Trolltechs
> license, which eventually spawned the
> Gnome project. Some people (like myself)
> still see Trolltech as just another
> money making business, rather than being
> truely part of the OSS community.


The word numerous is highly exagerated. The fuss was huge
but the only application that was ever found to have a
problem is KGhostView, because GhostView is GPL. All the
other apps were written for KDE and had no problems.


> (2) Releasing it under a Dual license
> QPL, GPL.
> Why not license a "library" under the
> LGPL?


Because they are making money with it. Is it such a bad thing
to make money and develop a GPL software at the same time
?

> or BSD? Obviously it was there
> strategy on the Windows platform side of
> things, keep it closed and make more
> money off it.


Indeed. Trolltech's CEO quote: Qt is free for use on Free
Software system. When windows becomes open source, we
will make the Qt version for Windows available under an open
source license




> (3) Ignoring OSS on any platform other
> than *nix.


Mmh, MacOs/X and the embedded platforms are not
necessarily unix, still Qt run on it. Anyway, I did not know
people on freshmeat were so fund of running programs under
windows. Maybe you should talk to the freshmeat
editors, ask them to include more windows software on
freshmeat. I know nices site for you, where they have tons of
windows software, you should have a look.



> Trolltech are more interested in profits
> than benefiting the general OSS
> community,


I think they are interested in both making profit and
providing the free software community with a good tool. Is it
such a shame, to make money and pay developers to develop
a program that is available under GPL ?



> multi-platform toolkit they're
> disadvantaging themselves, and
> discouraging a broad user-base over
> different operating systems. OSS happens
> not just on Linux, but a number of
> operating systems, OSX, *BSD, Windows,
> OS/2, BeOS etc...


Your list of unsupported platforms is completely wrong. Qt
(the free GPL version) works on BSD, QNX, Windows (with
cygwin). So they are missing OS/2 and BeOs ? (As far as I
know, those are dead platforms but let's just pretend they
are not). Nothing prevents OSS developers to port Qt on
these platform. Does Gtk run on BeOs ? Does FLTK run on
Os/2 ? I would be surprised. The reason it is not the case is
simply that nobody is intersted in it.



>
> Someone should remind Trolltech.
> OSS *is* Operating System Independant


I know very few OSS software that are as portble as Qt. To
my mind comes python, apache and perl. All the other are a
lot more linux-centric that Qt but I don't see you flaming
them.

For you information, this is the list of the operating
systems/compilers supported by Qt2. A lot more of them are
supported by Qt3.

hpux-n64 linux-pgcc solaris-64 win32 aix-g++
hpux-o64 linux-xscale solaris-cc win32-borland aix-xlc
hurd-g++ macx-g++ solaris-cc-gcc win32-g++
bsdi-g++ irix-64 netbsd-g++ solaris-g++ win32-gcc
cygwin-g++ irix-g++ openbsd-g++ solaris-kcc
win32-msvc dgux-g++ irix-n32 osf1-cxx sunos-g++
win32-symantec dynix-g++ irix-o32 osf1-g++ ultrix-g++
win32-visage freebsd-g++ linux-cxx qnx-rtp-g++ unix
win32-watcom hpux-acc linux-g++ qws unixware-g++
win32-xscale

Re: Another set of opinions
I basically agree, I was just treading a little more delicately on
the possibility of starting another Qt quality/licensing
flamewar.
^_^

Points worth noting: the Cygwin port of GPL Qt for X11
involves installing Cygwin, which isn't really an option for
many programs. The port to native Win32 isn't really done
yet, and there's been some significant debate over whether it
should be finished or not; Trolltech's experience so far has led
them to believe that releasing such a thing themselves would
cause them to lose much of their revenue stream, so while
the license allows such a port to be legally done there's some
concern that it wouldn't be polite to do. So for the time
being, this is a possiblility but not yet a reality.

The current situation is thus that for the deployment of
cross-platform software with Windows as one of the target
platforms, the main options are:

- Use the non-commercial version of Qt for Windows, which is
somewhat out of date and has a few restrictions (no ability to
set titlebar text, etc.) This is what I currently do for
PortaBase (a database program for the Zaurus, Linux
desktops, and Windows).

- Purchase a commercial license to Qt for Windows, which is
expensive for individual Free Software developers and
introduces a cost barrier for other developers helping
develop/debug the Windows port of the program. This is a
pretty good choice for companies writing anything halfway
important or complex, though. This is what I would like to do
for PortaBase, but I can't justify the cost in my case.

- Use the port of Qt for X11 to Win32, and help debug the
problems you will encounter along the way.

- Use wxWindows, and accept a slightly higher development
effort and possible Unicode problems on Win9x/ME.

- Code in Python instead and use either wxPython or PyQt (as
noted in the parent comment, the license isn't as much of a
problem in this case.) This is a really good choice for
in-house tools or niche programs due to development speed,
but nothing except C/C++ programs ever seem to succeed as
"everyday use by average person" apps due to concerns of
performance and installation dependencies.

- Code in Java instead and accept much higher memory
usage, worse performance, and even less chance than Python
of succeeding as an everyday app. Decent choice for
companies with Java programmers on hand, doesn't work too
well in most other cases. (I'm employed as a Java
programmer, and I acknowledge it as a pretty good choice for
server programming; it tends to fail miserably on the client,
though.)

Re: Another set of opinions

> The author mention that you must pay for
> a licencse to port
> your program. He overlooks the fact that
> Qt is already
> available for 3 platforms under the GPL:
>
> - unix/X11
> - MacOsX (X11 and native)
> - embedded platforms like the Zaurus

Yes, that's a mistake; I already sent the corrections in.

> Note that the embedded version of Qt can
> be used to run on
> the linux framebuffer
> (http://dot.kde.org/1058619204/)

Will be added, too.

> On windows, for close source
> development, you can also get a
> license of PyQt which is 5x cheaper
>
> (http://www.riverbankcomputing.co.uk/pyqt/buy.php).

Sorry, but I can't turn the whole internet upside down in order to compare prices; but thanks for the note, maybe it'll help someone.

> It doesn't use true native widgets on
> Windows and maybe
> MacOS X (although it looks pretty damn
> close), which is a
>
> Qt uses native widgets on Windows XP.
> Latest Qt uses native
> widgets on MacOs/X. For other platforms,
> the look is
> emulated.
>
> If I look at the so-called weaknesses of
> Qt, I find the article
> biased against it:
>
> 1. Very business-oriented main Web site
>
>
> Sorry, but I don't see how it relates to
> the quality of the
> toolkit. I find the Gtk's site ugly as
> hell but I would not
> mention that as a _weakness_ of Gtk. It
> does not relate to
> the toolkit.

I am not talking about ugliness or design. I am referring to content here. On the Gtk site I see direct links to FAQ, Documentation and Download, while on the Trolltech Site I wasted a lot of time searching for these things.

> 2. Main branch depending on one company
>
>
> So what ? Qt is GPL, you can fork it any
> time you want. Given
> that Qt is the income source of
> Trolltech, I don't see
> how they would not develop it. Is it a
> problem that MySQL
> develops MySQL ? Really, I don't see the
> point of this remark.

You can't compare MySQL with Qt. Qt is a huge package, and if Trolltech decides to change the license again, say to some closed source, it will take a lot of time until a strong fork is made, people gathered and development done.

> 3. Commercial developers and people
> wanting portability have
> to pay.
>
> See my previous remark on the various
> alternative options.

That's ok, but WRT the other toolkits that's a lot of hassle.

> 5. Objects not referred by namespace but
> simple literal prefix
> "Q"
>
> So ? Apart from a matter of taste, I
> don't see any problem
> here. Gtk object begin with G (or is it
> gkt_ ?)

..it depends on which part you refer to, like g_ for Glib, gtk_ for Gtk and Gdk_ for Gdk.

> and what is the
> point ?

C doesn't have name spaces, so the comparison is not valid.

> Q is shorter to type than 'using
> namespace Qt;' .

Now come on, maintainability and good code design
is better than some savings in typing! Apart from that,
use about 20 Qt things and you start getting more keystrokes than "using namespace Qt;" :)

> I
> personally never had any naming conflict
> with Qt. I would put
> that together with the uic: it is only a
> problem for C++
> purists.

Maybe, but then again I AM quite a C++ purist :P
Anyway, that's not a Qt bias - all toolkits except FLTK have this problem.

Leslie

Re: lol ?

> I fail to see the connection though. I
> thought freshmeat was a
> site on Free Software development, I was
> not aware that it
> had turned into a close source promotion
> site.
>

I think you are missing the point here - "open source" and "free software" aren't always the same thing. Truly free software gives the freedom of it's usage - i.e. you can modify sources, compile on whatever platform you want, sell your application build with it etc. This is not always the case in "open source" software - even in much loved GPL. A truly free license example would be BSD type of license.

The author's point about Qt was that it's not as free as the alternatives. For example, Qt is available for free only GPL'ed which means you can't even use it in closed-source but free (non-commercial) products.

I personally want to be free in how I'm using the code I've created. Ok, you can say that if I want commercial/closed source development then I can pay for Qt. The problem is that their pricing strategy is only good for big software development companies. I as a single developer simply cannot afford to pay that amount of money for it. Besides the price is ridiculous - for the same amount of money I can buy whole development product like Borland C++/Kylix.

Again I'd like to remind that author was not concentrating solely on open source development (for which Trolltech free licenses for Qt is most suitable).

Re: Qt pricing

>
> Oh, or you mean you can not write
> proprietary application
> with it. The author of the article seem
> to have the same
> opinion, that you should be able to
> write proprietary (==
> close source) application at no cost
> with a toolkit, else it is not
> a good Free Software toolkit.
>
> I fail to see the connection though. I
> thought freshmeat was a
> site on Free Software development, I was
> not aware that it
> had turned into a close source promotion
> site.
>
>

I just wanted to add that in commercial Qt usage I will have to pay for each platform I have to support - the lowest price is 1500 USD for single platform (either X11, Windows or Mac) and it's getting bigger with addition of the other platforms.

Now my point is: if I need limited portability of the application (let say between Windows and X11 - Qt lowest price 2325 USD) then I'm better of buying the complete software solution for that price. As I said before Borland C++ Builder/Kylix package is only 999 USD in lowest price (both products together). Plus there always are more free alternatives to Qt like wxWindows. Now answer me this, please - what's the pointg in buying that expensive library at all?

Re: Another set of opinions

> On windows, for close source
> development, you can also get a
> license of PyQt which is 5x cheaper

I believe you're wrong. While PyQt is 5x cheaper than Qt, you need a license for both to use PyQt. So it's really 120% as much.

Do I need the commercial version of PyQt?

The easiest way to answer this is to ask "Am I using the commercial edition of Qt?". If so then you also need the commercial version of PyQt. If you are using the GPL version of Qt, then you only need the GPL version of PyQt.

http://www.riverbankcomputing.co.uk/pyqt/faq.php

Note the implication here is that you already have a Qt license.

Also, note the words in the Qt FAQ at Trolltech:

Can I develop commercial applications with PerlQt or PyQt or other Qt wrappers?
Yes, if you have purchased a Qt Professional or Enterprise license. The licensing conditions are the same whether you use the Qt API directly in C++, or you use it through some API wrapper in another programming language. This means that all developers that write code containing calls to the Qt API (directly or through a wrapper) require Qt licenses.

http://www.trolltech.com/developer/faqs/general.html#q421

One more fly in Qt's ointment:

Can we use the Free Edition while developing our non-free application and then purchase commercial licenses when we start to sell it?
No. The Free Edition license applies to the development phase - anything developed without Professional or Enterprise Edition licenses must be released as free/open source software.

These are the reasons I haven't learned Qt... I don't mind the GPL, I have some project ideas for which it would be ideal... but I don't want to use a product that's going to force me to stay GPL forever, even if I'm the only contributor. I want to retain the right to re-release my code under new licensing if I see fit.

Re: Qt pricing

> Now my point is: if I need limited
> portability of the application (let say
> between Windows and X11 - Qt lowest
> price 2325 USD) then I'm better of
> buying the complete software solution
> for that price. As I said before Borland
> C++ Builder/Kylix package is only 999
> USD in lowest price (both products
> together). Plus there always are more
> free alternatives to Qt like wxWindows.
> Now answer me this, please - what's the
> pointg in buying that expensive library
> at all?
>


The point is that sometimes you need it. For many projects
wxWindows or one of the other toolkits will be a better
choice, but Qt does still have some features that they lack.
As I mentioned earlier, if you want a cross-platform
application that can display Unicode text on Windows 9x/ME,
Qt is just about your only choice. (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.)

So if you're writing an application that for business reasons
needs to support multiple languages on old versions of
Windows (data entry in multiple countries, language tutorial
to accompany a textbook, etc.) it's often well worth paying
the Qt license fee to avoid spending weeks hacking one of the
other toolkits to kind of work the way you want. Then again,
if you only need western European languages, or don't need
to support old Windows versions, or are just more picky
about the kind of license you're willing to accept, wxWindows
or one of the other options may well be a better choice.

Re: Tcl/Tk

> Tcl/Tk is just about the simplest-to-use toolkit
> there is, and it's cross-platform. True, on
> UNIX, Tk looks kind of old-fashioned and
> Motif-like, but I guarantee I can prototype a
> GUI in Tcl/Tk in about a tenth the time it would
> take with any of the other toolkits.
>

I'll agree with you that Tk is hard to beat for
speedily and easily prototyping GUIs, but I don't
like Tcl very much at all. The syntactic and
semantic conventions are inconsistent and crufty,
and the language as a whole seems to have been
designed in an ad hoc fashion. For instance,
Tcl's support for object oriented programming has
a long history of being either unavailable or
fragmented.

I think Python is a far better choice for GUI
prototyping. Not only can you use Tk within
Python, but you also have about half a dozen other
toolkits to choose from. A great toolkit (like
Tk) deserves a great language (like Python). I
dare anyone to point out a single advantage that
Tcl has over Python.

Re: Another set of opinions
% % 2. Main branch depending on one company

> You can't compare MySQL with Qt. Qt is a
> huge package, and if Trolltech decides
> to change the license again, say to some
> closed source, it will take a lot of
> time until a strong fork is made, people
> gathered and development done.

I do not agree. If Trolltech changes the license, we will just
keep the existing Qt and start maintaining it (most probably
in KDE). KDE developers have already a set of patches that
do not make it into Qt and that they would be glad to see
included. If trolltech ever decides to discontinue the Free
Software version, the fork is already ready to start.

Besides, in such an eventuality, the free Qt foundation
garantuees that if Trolltech does not release any free version
of Qt during one (or is it two ?) years, Qt becomes available
under a kind of BSD license.

Having talked to the CEO and a few head developers at
Trolltech, I can however guarantee that it won't happen. They
firmly believe in free software and Qt is "as free as they can
afford it to still make money with it".

> That's ok, but WRT the other toolkits
> that's a lot of hassle.

Yes, but is their level of support of the other OSes and the
internal quality of the toolkit as good as Qt ? I must
recognosid that I haven't used other toolkits much, but each
time I try, I am frustrated by how complicated it is to set-up
things and perform slightly complicated tasks.

> % Q is shorter to type than 'using
> % namespace Qt;' .

>
> Now come on, maintainability and good code design
> is better than some savings in typing!

I do not think the use of Q impers maintainability and code
design. It would be the case if the QString was named string.
In this case, you are sure to run into a conflict sometimes.
But I have never seen any other toolkit using conflicting
names with Qt.

Re: Another set of opinions

>
> % On windows, for close source
> % development, you can also get a
> % license of PyQt which is 5x cheaper

> I believe you're wrong. While PyQt is
> 5x cheaper than Qt, you need a license
> for both to use PyQt. So it's really
> 120% as much.

No, I am right. I have been owner of a Qt license in the past
and I am now owner of a PyQt license. I agree the statement
might be misleading, I'll try to explain:

> Do I need the commercial version of
> PyQt?
>
> The easiest way to answer this is to ask
> "Am I using the commercial edition of
> Qt?". If so then you also need the
> commercial version of PyQt. If you are
> using the GPL version of Qt, then you
> only need the GPL version of PyQt.
>
> http://www.riverbankcomputing.co.uk/pyqt/faq.php

This is to be understand, am I under the conditions where I
would need to buy a commercial version of Qt ? Then I need a
PyQt license. RiverBank computing has a deal with Trolltech
and it ships a commercial version of Qt (not the source but
the right to use it) with PyQt.

> Also, note the words in the Qt FAQ at
> Trolltech:
>
> Can I develop commercial applications
> with PerlQt or PyQt or other Qt
> wrappers?
> Yes, if you have purchased a Qt
> Professional or Enterprise license.

This question comes from the time where PyQt was not
available as a commercial version, only as a wrapper around
the free version of Qt. The question is to be understood as
"can I skip the free software aspect of Qt by using binding ?".
The question is worth asking because Qt is protected by GPL,
which is well known to apply on derivated product through the
linking phase of C++ compilation but is less clear in the case
of interpreted languages.

> The
> licensing conditions are the same
> whether you use the Qt API directly in
> C++, or you use it through some API
> wrapper in another programming language.
> This means that all developers that
> write code containing calls to the Qt
> API (directly or through a wrapper)
> require Qt licenses.

Indeed. But such a Qt licence is provided through the
commercial version of PyQt.

> These are the reasons I haven't learned
> Qt... I don't mind the GPL, I have some
> project ideas for which it would be
> ideal... but I don't want to use a
> product that's going to force me to stay
> GPL forever, even if I'm the only
> contributor. I want to retain the right
> to re-release my code under new
> licensing if I see fit.

Re: Qt pricing
% I just wanted to add that in commercial
> Qt usage I will have to pay for each
> platform I have to support - the lowest
> price is 1500 USD for single platform
> (either X11, Windows or Mac) and it's
> getting bigger with addition of the
> other platforms.

Yes, one thing can not be denied, Qt is expensive. It is not
affordable for a small business but so are many software
solutions. I think people are especially shocked by this aspect
because on the other hand, Qt is popular and free for Free
Software.

>
> Now my point is: if I need limited
> portability of the application (let say
> between Windows and X11 - Qt lowest
> price 2325 USD) then I'm better of
> buying the complete software solution
> for that price. As I said before Borland
> C++ Builder/Kylix package is only 999
> USD in lowest price (both products
> together).

If you compare it with other solutions available on windows in
C++, you won't find much. Kylix, WxWindow and that's it. Qt
has no runtime distribution fee, I don't know about Kylix but
most other development software on windows usually have
one which in the long term is largely equivalent to a Qt license.

I think that kylix is indeed a valid alternative. I don't know
how sophisticated it is. What I have heard is that it is really
easy to use but slightly less powerful than Qt in some areas,
and more in others.

Now, as someone familiar with free software, I choose Qt over
Kylix because I am more familiar with KDE and Qt. Somebody
familiar with borland would certainly make the other choice.

Re: Tcl/Tk

> The author wrote: Tcl/Tk isn't much
> better [than xlib]
> That's complete nonsense. Tcl/Tk is
> just about the simplest-to-use toolkit
> there is, and it's cross-platform.
> True, on UNIX, Tk looks kind of
> old-fashioned and Motif-like, but I
> guarantee I can prototype a GUI in
> Tcl/Tk in about a tenth the time it
> would take with any of the other
> toolkits.
>

Your stated target audience is those who want to
start developing GUI applications with goals of
comparison and introduction.

People who wish to build the next killer game
or application likely need no introduction at all.
However, those with either lesser goals or have
a need for fast development and friendly learning
curves for business/industrial in-house applications
or who wish to earn a living producing such customized
GUI applications would be well served by using Tcl/Tk
as many large companies in the world have done.

It is an unfortunate and somewhat silly situation
that so many large companies do use Tcl/Tk but often
have to create their own developers rather than
hire them. But then again, that reflects upon the
nice learning curve.

Re: Tcl/Tk

>
> %
> % Then again, maybe you should
> % have a look at Tcl/Tk in turn.
> %
>
>
> You're right. Can you think of a good
> example of a Tcl/Tk app that I should
> look at?

InstallBase

Written entirely in Tcl/Tk with no further C extensions.

Re: Another set of opinions

> % Q is shorter to type than 'using
> % namespace Qt;' .
>
> Now come on, maintainability and good
> code design
> is better than some savings in typing!
> Apart from that,
> use about 20 Qt things and you start
> getting more keystrokes than "using
> namespace Qt;" :)
>
>
> % I
> % personally never had any naming
> conflict
> % with Qt. I would put
> % that together with the uic: it is only
> a
> % problem for C++
> % purists.

Using "Q" to start classes is indeed a use of namespaces; just not C++ namespaces. Either way, it's really quite similiar. If you begin all of your classes with the letter "Q", and have a conflict with one of Qt's classes, for example "QObject", it's similar to using the namespace "Qt" always and having a class named "Object".

Qt doesn't use C++ namespaces because many compilers, such as IRIX's mipspro, have horribly broken implementations of namespaces. I had a real bad time trying to get boost to work on it (no, gcc isn't an option, me != admin)

Re: Another set of opinions

> if Trolltech decides
> to change the license again, say to some
> closed source, it will take a lot of
> time until a strong fork is made, people
> gathered and development done.

If Trolltech decides to close Qt's source, the last version would automatically be released under the BSD license (see http://www.kde.org/whatiskde/kdefreeqtfoundation.php)

Not that this would ever happen; more than half of Trolltech's developers have been KDE developers at one point or another, and Trolltech, as a company, is very pro-open source (i.e, they don't want anything bad to happen to kde, which provides valuable talent and testing for Qt). If it did happen, a fork would take *very* little time to organize; a copy of qt, with additional patches, is already well maintained inside of kde's cvs.

Re: Qt pricing

>
> If you compare it with other solutions
> available on windows in
> C++, you won't find much. Kylix,
> WxWindow and that's it.

Nop - there are more choices than that - world does not end with Qt and wxWindows being the only choices. In fact this article gives several other choces for cross-platform development. All your talking that everything is much easily done in Qt than let say in wxWindows (or in FLTK for that matter) is just a matter of experience with that or another library. I bet you are using Qt for ages - hence you get used to its way of doing things so the other libraries are not as comfortable to you as Qt is. But then - you are being subjective to the other libraries. People using wxWindows for ages will object and say that it's the easiest thing to use (once you are familiar with it).

Plus there's always Java ;-))). Talking about java client being slow etc - look at SWT graphics in Eclipse. Still even client application using Swing/JFC could look professional and be fast. In case of Swing/JFC, it's not the library that makes it slow - it's how the developer uses it.

> Qt
> has no runtime distribution fee, I don't
> know about Kylix but
> most other development software on
> windows usually have
> one which in the long term is largely
> equivalent to a Qt license.

Well that's a surprise - can you give me an example of "most other development software on windows" that asks you about additional fee for runtime redistribution? Neither Microsoft's Visual Studio product line nor Borland's products for any platform requires you to pay additional fees for runtime redistribution (this is included in the product price already - otherwise what are you paying for?). You can of course pay extra for the extended support but this is also the case in Qt.

>
> I think that kylix is indeed a valid
> alternative. I don't know
> how sophisticated it is. What I have
> heard is that it is really
> easy to use but slightly less powerful
> than Qt in some areas,
> and more in others.

This is nonsense - Kylix implementation of VCL (Borland's libraries of controls/widgets) is implemented on top of Qt (don't know which version though).

Re: Qt pricing
% All your
> talking that everything is much easily
> done in Qt than let say in wxWindows (or
> in FLTK for that matter) is just a
> matter of experience with that or
> another library. I bet you are using Qt
> for ages - hence you get used to its way
> of doing things so the other libraries
> are not as comfortable to you as Qt is.
> But then - you are being subjective to
> the other libraries. People using
> wxWindows for ages will object and say
> that it's the easiest thing to use (once
> you are familiar with it).

Yes, I have been using Qt for ages. But after two days of
using it, I was proficient with it, that's for me the most
important. I did not need few month to get used to how
things are done, it felt just natural. The toolkit really well
designed and complete, with copious documentation.

I know other people who had exactly this same experience. I
even have a mail of somebody who put complete beginners
both in programming and C++ in front of Qt, and had them
being proficient after one month. That's something.

> Plus there's always Java ;-))).

Java has its own set of issues (http://216.239.37.104/search?q=cache:6LfSy9DmCM8J:ftp.ipv4.heanet.ie/pub/trolltech/pub/qt/pdf/qt-vs-java-whitepaper.pdf+java+qt+comparison&hl=en&ie=UTF-8),
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.

> Well that's a surprise - can you give me
> an example of "most other development
> software on windows" that asks you about
> additional fee for runtime
> redistribution?

A windows friend told me that but I did not check thorougly. I
know he was surprised by the absence of runtime fee.

> This is nonsense - Kylix implementation of VCL (Borland's
libraries of
> controls/widgets) is implemented on top of Qt (don't know
which version
> though).

Based on Qt does not mean you get all the power of Qt. Does
Kylix run on MacOsX and Zaurus ?

For example, I was told that in VCL, you can not connect
multiple signals to a slot (you have to translate to the
equivalent of signal and slots), which I find fairly limiting.

Re: Qt pricing

%
> Yes, I have been using Qt for ages. But
> after two days of
> using it, I was proficient with it,
> that's for me the most
> important. I did not need few month to
> get used to how
> things are done, it felt just natural.
> The toolkit really well
> designed and complete, with copious
> documentation.
> I know other people who had exactly this
> same experience. I
> even have a mail of somebody who put
> complete beginners
> both in programming and C++ in front of
> Qt, and had them
> being proficient after one month. That's
> something.

This is a typical example of Visual Basic syndrome ;-) Usually, couple day is enough to get proficient with it. But it does not mean that you will be ready to create a good performing GUI application in those two days. To create professionally looking UI without any performance problems - any toolkit will take you several months to adapt to its features. By performance problems I mean loading big chunks of data (typical for enterprise wide applications) into controls/widgets without slowing down UI or easting up all memory.

What I mesan by all this is that there is always a difference between just using the toolkit and using it effectively.

>
> % Plus there's always Java ;-))).
>
> Java has its own set of issues

I've read this article before - again it's author not using Swing/JFC (judging from it's examples) effectively. For example it's tree creation example in Java could be rewritten in much shorter and understandable way. Also JFC/Swing is designed with "handling (large) data effectively" in mind - therefore it has UI and data separation (i.e. each widget accessing data not directly but through data model interface defined for that class of widgets). For instance table/grid widget access the date it's displaying via class implementing table model interface that provides grid-like data access. The underlined data can be cached, paged (if large) or loaded completely without widget ever knowing the difference or setting any flags. The same data could be shared between several models being a source for displaying in several controls (although people are always forgetting this - hence data inefficiency and memory hungry applications).

When I was starting to work with Java seven years ago - I also had my doubts (about suitability for UI). But all changed after similar discussion with one guy from Borland's JBuilder (which is an excellent example of how to code UI effectively) development team. He simply showed me how fast Java UI could be when used effectively and with consideration.

I still don't think that java is not good enough for designing small and fast applications (embedded apps go to this category).

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

Certain incompatibility exists - between major release versions (in Java they are always the second number like from 1.1 to 1.2 etc) but then I doubt that the Qt 2.0 and 3.0 are completely compatible. Plus statement about jdk version is not true - latest java versions available on all the same platforms as Qt (with exception of embedded devices).

>
> Based on Qt does not mean you get all
> the power of Qt. Does
> Kylix run on MacOsX and Zaurus ?

Only MacOS X is yet unsupported - all linux variants mostly are simply because Borland supplies sources of VCL with commercial versions of its products. But if the ultimate cross-platform compatibility is the goal then my choice may be different (wxWindows?).

>
> For example, I was told that in VCL, you
> can not connect
> multiple signals to a slot (you have to
> translate to the
> equivalent of signal and slots), which I
> find fairly limiting.

VCL operates in different terminology using events and event handlers. But nothing prevents you from having single event handler for several events simultaneously (is that's what you mean).

Finally, it's strange for me to have this discussion withyou having deep knowledge of Qt and having tried other toolkits only briefly or just having heard of them from other "experienced" people. I prefer to establish my own opinion on usability of that or another library/toolkit by trying to use it and not just briefly. Hence I found this article really useful as, for instance, I have never heard of FLTK before and I'm willing to give it a try.

This is my last post to this matter.

PS: to all Qt maximalists - there was a nice article about it by Al Stevens (C++ column writer) in Dr.Dobbs somewhere in 2001-2002. He actually pinpointed Qt weaknesses (some of them mentioned but argued here). So you might want to take a look at that.

Eclipse/SWT and why QT&GPL is a problem
just to mention it: Eclipse-SWT is a very nice Java toolkit, which reuses Widgets of Motif, GTK2, WIN32, OS-X, Pocket-PC in a "native" way. It's X-platform and very fast. By using a free java platform like GCJ you can write Java-programs totally based on Free/Open-Source Software.

Concerning QT, i think the author is right pointing out the GPL-problem. I think the GPL is a bad idea for a GUI-Library. It not only prohibits the linking of commercial software, but also the linking of all the free/open-source software applications/libraries which use different licenses (like LGPL). It might be illegal to write QT-language-bindings for Perl, PHP, Java,... (depends how you do it) and it is definitely illegal to port something like SWT or OpenOffice to QT (They are not GPLed).

IMHO the GPL is a good idea for applications or tools, but not for basic things like GUI-Toolkits.

Re: fundamental errors with QT

Ehm, that the problem isn't if you can use the toolkit on a platform, the problem is that you cannot use it a FREE SOFTWARE on every platform... OSS is platform independant... Get it, now?

Did you consider reading the post before you replied?

Dennis

Re: lol ?

> GTK+
> LGPL, ok, but looks ugly

Looks ugly? You must be thinking of GTK1. GTK2 looks beautiful, check some screenshots on http://art.gnome.org. There are themes easily nicer than Keramic (depending on how much you like Keramic of course).

> And gtk is only a raw toolkit, not a
> Appframework.

Yes, the author might have wanted to mention GNOME. On the other hand, GNOME certainly isn't cross-platform.

> And then u call this RAD ?
> A gui designer doesnt count for me as
> the only thing u need for RAD.

Check out Anjuta at http://anjuta.sourceforge.net.

wxWindows and Qt
I am tending towards wxWindows because it is free, it uses native widgets, it is well designed, and it has a good community. I'm just sorry it doesn't use modern C++ including the STL.

With its support of so many platforms and languages it is truly the 'universal' toolkit. Actually, I think they should rename it to that!

As for Qt, why are people attacking Trolltech/Qt? Sure they are trying to make money, that's what companies do. If you think they are bad then you should take a look around you. Consider for a moment Microsoft,IBM,Sun,SCO,etc. Or my local computer companies, Corel and ATI - both are nasty companies with aggresive, dishonest, and corrupt leaders (Copland and Ho are guilty of flagrant insider trading). Give me Trolltech anyday!

I would never use their toolkit because I want something that is free to use on all major platforms. And I'm very sorry that they caused such a harmful split in the Linux community - they made a big mistake. But I still think they are about as good a corporate 'citizen' as there is.

Tom.

Re: Eclipse/SWT and why QT&GPL is a problem

> just to mention it: Eclipse-SWT is a
> very nice Java toolkit, which reuses
> Widgets of Motif, GTK2, WIN32, OS-X,
> Pocket-PC in a "native" way.
> It's X-platform and very fast. By using
> a free java platform like GCJ you can
> write Java-programs totally based on
> Free/Open-Source Software.
>

The problem with SWT is that it is released under an open-source license incompatible with the GPL. So you cannot use GPL-covered code in applications that use SWT. This hampers the collaboration (code sharing) with many pieces of free software.

It would be great for the free software community if IBM double-licensed SWT, adding the LGPL (or the GPL) as an option.

--
srmq

gettext
Although I can believe that Qt's integrated internationalisation is better, it makes much more sense to stick to the UNIX philosophy of having one program do one job only and do it well. If the capaibilities of gettext are lacking, it would be much better to improve it than to write a whole new system, integrated into GTK+ or Qt where it is of no use to other programs which don't use the toolkit. Integrating things to the point of excluding their independant use is a mistake in my opinion.

FLTK cool tool also for PDA
I used FLTK to build a "moving map" GPS program that runs on both Linux and Windows, but even cooler also on an Agenda PDA (www.softfield.com). Just recompile for the right platform and off you go.

Re: Eclipse/SWT and why QT&GPL is a problem

> the linking of all the free/open-source
> software applications/libraries which
> use different licenses (like LGPL). It

Well, it is legal to link LGPL and GPL code. The resulting derivative work may be distributed only under GPL, but LGPL allows this.

> like SWT or OpenOffice to QT (They are
> not GPLed).

OpenOffice is GPLed (et least the Debian version).

What about Java?

I just don't understand why Linux / Open Source programmers would rather spend lots of extra time and effort hacking out a GUI in C or C++. I used to program directly to Xlib, and I feel the same way as the toolkit users who would feel sorry for somebody using straight Xlib.

With Java you get a simple and powerful API for creating UIs. You get more advanced graphics features than pretty much everything out there (anti-aliased everything, real transforms, geometry, alpha/composites, extremely optimized pipeline, pluggable look and feels, event-based callbacks, automatic pacing and coalescing of repaints, internationalization, etc).

And then you get other Java benefits like working on every operation system, reflection, garbage collection, weak/soft references, huge library of useful stuff like zip, regex, crypto, XML, etc.

Finally, Java itself is not slow and does not use a lot of memory. It used to be at least 40x slower but now it's the speed of unoptimized C or better. Programs can even call overridden methods dynamically at runtime (ie, lookup method by string variable) at only 1/5th the speed of a static compiled call in C++. That's freakin unbelievable. And most 'hotspots' are actually optimized better than in C++.

Compared to other toolkits, Swing (the UI part of Java) starts up slowly and uses a lot of memory (it was designed by former Smalltalk people...). But once it's up and running it's fast and doesn't use much extra memory. So it isn't suitable for simple applications for that reason, but for medium or large ones it's an excellent choice technically speaking.

Most of the difficulty is due to the operating system fighting Java; if you've ever used Java on Mac OS X for instance you'll know how beautifully it integrates with the OS. A Mac user can just double-click on an executable JAR file (ZIP format) and they can just double-click and it runs like any other app, looks like any other app, and shares memory with other Java apps so it doesn't take many resources. On Windows, they have to install Java first and each Java app takes substantial resources. On Linux Java it's an even worse situation.

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

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.

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

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.

Re: What about Java?

The GUI API in Java is surely modular and objected oriented. I guess speed is one big issue with Java. On a slow system the GUI really crawls. That coupled with the fact that there is no native Java support on some *nix's like FreeBSD makes me (and I guess other ppl too) stick to C/C++ for GUI programming.

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: What about Java?

>
> I just don't understand why Linux / Open
> Source programmers would rather spend
> lots of extra time and effort hacking
> out a GUI in C or C++. I used to
> program directly to Xlib, and I feel the
> same way as the toolkit users who would
> feel sorry for somebody using straight
> Xlib.
>
> With Java you get a simple and powerful
> API for creating UIs. You get more
> advanced graphics features than pretty
> much everything out there (anti-aliased
> everything, real transforms, geometry,
> alpha/composites, extremely optimized
> pipeline, pluggable look and feels,
> event-based callbacks, automatic pacing
> and coalescing of repaints,
> internationalization, etc).
>
> And then you get other Java benefits
> like working on every operation system,
> reflection, garbage collection,
> weak/soft references, huge library of
> useful stuff like zip, regex, crypto,
> XML, etc.
>
> Finally, Java itself is not slow and
> does not use a lot of memory. It used
> to be at least 40x slower but now it's
> the speed of unoptimized C or better.
> Programs can even call overridden
> methods dynamically at runtime (ie,
> lookup method by string variable) at
> only 1/5th the speed of a static
> compiled call in C++. That's freakin
> unbelievable. And most 'hotspots' are
> actually optimized better than in C++.
>
> Compared to other toolkits, Swing (the
> UI part of Java) starts up slowly and
> uses a lot of memory (it was designed by
> former Smalltalk people...). But once
> it's up and running it's fast and
> doesn't use much extra memory. So it
> isn't suitable for simple applications
> for that reason, but for medium or large
> ones it's an excellent choice
> technically speaking.
>
> Most of the difficulty is due to the
> operating system fighting Java; if
> you've ever used Java on Mac OS X for
> instance you'll know how beautifully it
> integrates with the OS. A Mac user can
> just double-click on an executable JAR
> file (ZIP format) and they can just
> double-click and it runs like any other
> app, looks like any other app, and
> shares memory with other Java apps so it
> doesn't take many resources. On
> Windows, they have to install Java first
> and each Java app takes substantial
> resources. On Linux Java it's an even
> worse situation.
>
>

Um.. How about the fact that programmers dont like being forced to program a certain way? Or the fact that the Swing looks like crap? Or the fact that noone likes eating up all their memory and waiting 30 seconds for the simplest of programs to start up? Or the fact that Java GUI programs almost NEVER look/work the exact same across multiple platforms - although that is the language's supposely primary benefit.

For large distributed projects with multiple developers in a controlled business environment, Java make be a good fit, but outside of that, I'd MUCH rather use a GTK client than a comparable Java one.

My experience has been that GTK, QT, and FLTK apps are WAY faster, they look better, and are overall a much higher quality user experience than comparable Java apps - even on cutting edge hardware.

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 :)
>


Microsoft does a very good job at maintaining backward
compability, at least in their C/C++ area. You can still compile
16 bits windows 3.1 application on windows 2000.
Unfortunately for them, they forgot this wise principle when
working with other products (access, visual basic, word, ...)

Re: Qt pricing

> % Plus there's always Java ;-))).
>
> Java has its own set of issues,

Link was broken but presumably to:
ftp://ftp.trolltech.com/qt/pdf/qt-vs-java-whitepaper.pdf

This article is complete junk. They say compiling Java code is slow becuase the compiler is written in Java and "Java is slow". Meanwhile the entire class library (1.3 million lines of code) takes only 5 minutes to compile on a laptop. How long does Qt take to compile? And it does what, 1/10th the stuff, at most?

The rest of the article says goes to lengths to avoid admiting that Swing is a better API (see where they say "the Swing example looks simpler" but oh yeah Java is slow so that means Qt has a better API). It's shameful.

Re: What about Java?

>
> %
> % I just don't understand why Linux /
> Open
> % Source programmers would rather spend
> % lots of extra time and effort hacking
> % out a GUI in C or C++ [instead of
> % Java/Swing].
>
> Um.. How about the fact that
> programmers dont like being forced to
> program a certain way? Or the fact that
> the Swing looks like crap? Or the fact
> that noone likes eating up all their
> memory and waiting 30 seconds for the
> simplest of programs to start up? Or the
> fact that Java GUI programs almost NEVER
> look/work the exact same across multiple
> platforms - although that is the
> language's supposely primary benefit.

Go visit the Mac store and try some Java apps on OS X. Try http://www.jgoodies.com/ on the Mac or Windows. On Mac you won't need to install Java, and it'll show you that you are wrong on all accounts above. Why does Linux make it so difficult for Java apps? I can understand why Billy G wants to make it hard.

Re: What about Java?
% Go visit the Mac store and try some Java apps on OS X.

This is twice that you have spoken of the glory of Java on Mac OS X without qualifying the version -- prior to Jaguar (10.2) [possibly the 2nd or 3rd time u spent money on Mac OS X] the support was poor. Java performance is still not great.

Sun's Solaris engineers appear to not even want to use Java:
http://www.internalmemos.com/memos/memodetails.php?memo_id=1321

Re: Tcl/Tk

>
> The syntactic and semantic conventions are inconsistent
> and crufty, and the language as a whole seems to
> have been designed in an ad hoc fashion.

I would strongly disagree here. Tcl's syntax rules
are very consistent. Tcl's syntax rules fit on less that two pages. Tcl is more of a language of commands, not one
of syntax. You shouldn't expect Tcl to behave like other
languages, similar to expecting a tab to be the same as
eight spaces.

> For instance, Tcl's support for object oriented
> programming has a long history of being either
> unavailable or fragmented.

Object oriented programming with Tcl has been around
for 11+ years, IncrTcl being the most popular. Most
mainstream Linux distributions ship IncrTcl. I wish it was
included in the core distribution, but it's certainly easy to add. (see below)

> I dare anyone to point out a single advantage that
> Tcl has over Python.

Ok, without trying to start a flamewar (I like Python too),
here are things that come to mind:

- The Tcl event loop and fileevents (not the same as 'select' or threads).

- tclkits (one or two file packaging of Tcl, libraries, extensions, and your application). Makes installing a full application as easy as cp myapp /to/someplace, without having Tcl already installed on the target machine.

- choice of O-O programming: IncrTcl, XOTcl, many others. Not everyone thinks of O-O on the same terms.

Of course, there is much more similarity between Tcl and Python than there are differences. Happy programming.

Re: Another set of opinions

>
>
> % I believe you're wrong. While PyQt is
>
> % 5x cheaper than Qt, you need a license
>
> % for both to use PyQt. So it's really
>
> % 120% as much.
>
>
> No, I am right. I have been owner of a
> Qt license in the past
> and I am now owner of a PyQt license. I
> agree the statement
> might be misleading, I'll try to
> explain:
>

Oh, you are *so* wrong. You probably ought to get rid of that e-mail address asap before tt comes hunting you for a license ;o) The commercial version of PyQt requires that you have purchased the commercial version of Qt. In fact, the PyQt build process looks for an appropriate version of Qt and refuses to compile if you try to use PyQt Commercial with Qt GPL.

Re: Qt pricing
Java is great for tiny little apps, but it needs a tiny little
VM in such cases. Firing up a full-blown J2SE VM for the
equivalent of a typical Tcl/Tk script would make it seem
quite sluggish and resource-hungry indeed.

Re: Eclipse/SWT and why QT&GPL is a problem

> just to mention it: Eclipse-SWT is a
> very nice Java toolkit, which reuses
> Widgets of Motif, GTK2, WIN32, OS-X,
> Pocket-PC in a "native" way.

Let's just dispel the myth right now that SWT Java applications look "most" like the native OS out of all Java applications.

It takes a good 5 minutes to make a Hello, World!-style program which displays a button in a window. Make one of these for each of AWT, Swing, and SWT, and lo and behold, Swing is the only one where the button created actually looks like a button on my version of Windows.

Of course, if you're into developing applications which look like Windows 2000, that's another story. Not everyone is so keen on looking like legacy.

Qt from a professional perspective.
I am currently a contractor for Sandia Natl. Labs (www.sandia.gov). I was to create a cross-platform CAD/CAM solution for freeform fabrication. I looked at several toolkits and here is why I choose Qt:

1) Support. For people with commercial licenses, all emails are responded to by a professional developer who works with you until your problem is resolved.

2) Integration. I didn't need to find several libraries or tools to solve my needs for XML DOM, OpenGL, cross-platform build system, and translation.

3) Feature Requests and Maintenance. Since my license helps support Qt development in a very direct way, feature requests and bug reports are taken very seriously. Qt having a team of full time developers, guarentees me the package's steady evolution.

4) Documentation. The documentation is supurb. The official reference and tutorial collection is great.

5) Cross-platform support. No other toolkit comes close to the Windows/X11/OSX compatibility.

None of the other toolkits out there met this criteria. Although my reasoning isn't orthoginal to open-source developers . . . it might be useful to see this perspective as well.

Re: Qt from a professional perspective.
David -- thank you for the post, kept me from having to make the exact same post :)

Breaking out of the Box
My concern is that the bulk of applications created limit
themselves to the current idiom. This has the apparent
benefit that 'everyone' understands the paradigm.
However it leaves little room for enhancements. Why
does the article makes no mention of accessibility? Is
keyboard, or switch support fully integrated in all cases?
Can buttons be resized by end-users? can they edit
toolbars? can they zoom in on part of the application of
interest?

My particular research is with people who have severe
learning difficulties, many of whom cannot read. SVG
scaleable vector graphics offer an opportunity to define a
workspace that is not so absolutely cartesian, and ours is
http://www.peepo.co.uk . It has non-rectangular buttons
with shaped borders that highlight on use, it plays a
sound file on use,
http://www.peepo.com/crap/argo3/ offers the
opportunity to manipulate a web based GUI freestyle.
One day a dashboard might be somewhat like this :-)
Cartographers also seem to like SVG.

Does anyone have an example of an application that has
broken out of the box?

My knowledge of GUI Toolkits is extremely limited, but
OPIE
VB6 used to exist
Isn't there a javascript/DHTML toolkit?
XForms is free it is a W3 standard:
http://www.w3.org/MarkUp/Forms/

It would be nice to have some screenshots OPIE has some
excellent ones here: http://opie.handhelds.org/gallery/
are there any for fltk?

Re: What about Java?
So why did I switch from Java to Python/wxPython and
restarted my project?
1. Java did not allow me to adapt the color and size of each
cell in a grid or table row individually to its content. With
wxPython I can adjust the color as well as the height and
width of each cell.
2. According to Bruce Eckel (author of 'Thinking in Java'
and of 'Thinking in C'), as well as according to other
professional programmers, with Python, programming
towards a given goal is up to 10 times faster and the
afterwards, the programm is much easier to debug and to
maintain.
3. Licence, Qualitiy and Money: I did use Borlands
J-Builder. On the first view, it was a nice toy. But you can
not use it for open Source development. It turned out to be
buggy and to complicated as I wanted to do more than the
the simplistic application they seemed to have in Mind.
Further more, J-Builder war expensive and every few month
the have a new expensive update.
So now I use EMACS with Python, wxPython and
wxDesigner instead, and I am very happy to have switched.
It is better quality, with a better licence for less money.

Re: Qt from a professional perspective.
% 1) Support. For people with commercial
> licenses, all emails are responded to by
> a professional developer who works with
> you until your problem is resolved.

With wxWindows/wxPython they too have a very good
support by their e-mail-Lists.
Further more, if can and will pay one of the core developers
as much or even just halve the money you have to pay to
Trolltech as a professional, I am very shure, you get at least
the same quality of support as well as the same
responsivness to feature requests

Re: What about Java?
This post was better written and longer, then I accidentally closed the browser tab *slap self*.

To get down to it, it's all about personal preference. Certainly you do not see advantage to using C and Xlib. The advantage is speed (of execution) when one has it proper. Of course the disadvantage is that it sucks to use, which is what the author of the review states.

You prefer to use Java and Swing, that's fine. There are others that prefer using C++ and wxWindows. Functionally, they offer very much the same thing; object orientation, portability, etc. Certainly there are major differences between the two, but if you had the chance to use wxWindows, you'd find that wxWindows, as well as all the other toolkits given, offer nearly all the features of Swing, without being tied to Java.

Hell, if we wanted to go a step farther, and even use a language that is easy to develop with, can be used with any of the given libraries, Python can be used (including GTK, which the author is mistaken on). It offers many, if not all of the bonus features of Java, and with any of the GUI toolkits given, offers GUI features at least as good as Swing.

Certainly this only matters if one uses a language other than Java to develop a GUI, but one thing made abundantly clear in your post is that you poo-poo on any language+GUI toolkit combination that is not Java+Swing.

Hey, you are entitled to your own opinion. But remember, one of the many reasons people program is because it offers choice. Java+Swing is ONE OF MANY chioces. It's the right choice for you and for many others, but for the makers of any non-java piece of software utilizing a GUI, Java+Swing is not the right choice.

Re: What about Java?

> 1. Java did not allow me to adapt the
> color and size of each
> cell in a grid or table row individually
> to its content. With
> wxPython I can adjust the color as well
> as the height and
> width of each cell.

Call table.setDefaultRenderer. The renderer is usually a label component (but can be anything) and you set the color, width, height, etc on that. Or you can have it draw anything you want. This is much more flexible that other toolkits and only takes a small time to get use to.

> 2. According to Bruce Eckel (author of
> 'Thinking in Java'
> and of 'Thinking in C'), as well as
> according to other
> professional programmers, with Python,
> programming
> towards a given goal is up to 10 times
> faster and the
> afterwards, the programm is much easier
> to debug and to
> maintain.

So use JPython/Jython then. You'll get to write your scripts AND use a better GUI library for them.

> 3. Licence, Qualitiy and Money: I did
> use Borlands
> J-Builder. [...]

You're comparing J-Builder with emacs?

> So now I use EMACS with Python, wxPython
> and
> wxDesigner instead, and I am very happy
> to have switched.
> It is better quality, with a better
> licence for less money.

Look, Java isn't for everyone but from the sound of it I seriously doubt most of y'all responding know enough about Java to make an informed decision past just personal preference. That's fine, we can't know everything about everything. I would have liked to see Java+Swing or Java+SWT in the article.

FOX, Qt
In the FOX description:
>That hurts me, and I think to myself, "Why don't
>they provide a class for this? Why does someone
>write a library in C++ if he misses some of the
>fundamental concepts of the language, like data
>encapsulation?"
I believe it is the author of the article, not the authors of FOX who miss the point of C++. The point of Java is to force programmers to use object oriented programming, with one specific object oriented paradigm/style. If a programmer fails to use data encapsulation, etc. then they are missing the point of Java.

In C++, the point is to give the programmer a general set of tools, and rely on the programmer to pick the right programming paradigm. Sometimes this is object oriented, of one of the many styles/paradigms thereof. Sometimes, it's template-based, and sometimes it's structured. It's designed to provide as much flexibility as possible, and rely on the programmer to use discipline to maintain consistancy with whatever style they choose. This means there are properly designed pieces of C++ code that explicitly do not use encapsulation/data hiding. Languages like Java were created as a reaction to languages like C++, where the language designers found that significant numbers of mediocre programmers, as well as almost all beginners, were misusing the language, and so tried to force a specific paradigm onto the programmer.

I've never used FOX, so they may be misdesigning something, but this isn't by missing the concepts of the language. If you want to have the language to have concepts about how a person should program, go with a language designed for beginners or mediocre programmers, like Java or Pascal. C++ ain't got it.

On a side note, to the person who posted "Another set of opinions," it is very much not true that "Qt is by most accounts the best designed, fullest featured, and fastest to work with C++ GUI toolkit out there." Look at the number of Gnome developers, most of whom would disagree. I mostly dislike Qt because it is very heavy-weight, and forces a lifestyle change. It forces me into a very specific programming paradigm, programming language, requires me to structure my code around the structure of the toolkit, wants me to run my code through additional compilers, etc. I can, for instance, take an arbitrary piece of code, and add a GTK interface to it, or take a properly written piece of GTK code, and make it into a text-mode version. With Qt, I have to restructure my code to fit Qt's world view, and once Qt is merged into a bit of code, getting its grubby claws out is a royal pain.

I guess another way of putting it is that Qt is an application framework, rather than just a GUI toolkit. GTK has application frameworks on top of it, just as the Windows API has MFC on top of it (which is actually lighter-weight than Qt), but both allow access to the GUI toolkit without requiring the framework. This isn't the case for Qt. This limits a significant set of apps I would want to write

Qt is nice for very rapid prototyping of applications, and having the amount of framework they include and require is nice for most (but not all) applications. However, I find the lack of flexibility, in terms of global program structure and style, languages, etc. to make it fairly subideal as a general-purpose GUI toolkit. This bites you whenever you're doing anything non-standard, and in a lot of cases, where you are using two libraries with the same sort of take-over-the-world approach, but an incompatible way of taking over. I don't think a GUI toolkit that only works for 90% of the applications out there is a good solution.

Re: Eclipse/SWT and why QT&GPL is a problem

i thought you can link GPLed apps to anything (for instance the windows-api, the sun-java-libraries...). there are loads of GPLed applicatons/libraries which do that.

Re: Eclipse/SWT and why QT&GPL is a problem
yes you are right with the LGPL. but what if someone writes an extension to Openoffice using an artistic, BSD, MPL... license. This extension can not be distributed with the (because of QT) GPLed version of OpenOffice...

What i wanted to say is that a basic gui-library should "leave the door open" to applictions using other licenses which are common in the open-source world...

Re: Eclipse/SWT and why QT&GPL is a problem

>
> i thought you can link GPLed apps to
> anything (for instance the windows-api,
> the sun-java-libraries...). there are
> loads of GPLed applicatons/libraries
> which do that.
>

No you can't. This only applies for linking to "standard system libraries", which the SWT clearly is not. See this section of the GPL FAQ: http://www.gnu.org/licenses/gpl-faq.html#WritingFSWithNFLibs (http://www.gnu.org/licenses/gpl-faq.html#WritingFSWithNFLibs)

Re: Eclipse/SWT and why QT&GPL is a problem

>
>
> Let's just dispel the myth right now
> that SWT Java applications look "most"
> like the native OS out of all Java
> applications.
>
> It takes a good 5 minutes to make a
> Hello, World!-style program which
> displays a button in a window. Make one
> of these for each of AWT, Swing, and
> SWT, and lo and behold, Swing is the
> only one where the button created
> actually looks like a button on my
> version of Windows.
>
> Of course, if you're into developing
> applications which look like Windows
> 2000, that's another story. Not
> everyone is so keen on looking like
> legacy.

It's not a myth. SWT uses native widgets. A program using SWT doesn't look "most" like the ones of the native OS, because it doesn't try to just immitate it like Swing does (until jdk version 1.4.1, version 1.4.2 can use native widgets), but it actually uses the native widgets. If your SWT application "doesn't look right" you probably did something wrong.

Re: Eclipse/SWT and why QT&GPL is a problem

well - as eclipse is currently being ported to gcj by redhat, swt will become a kind of 'system-library'. (if they create a seperate package for swt).

i think, this part of the GPL is a bit fuzzy: what are "major components (compiler, kernel, and so on) of
the operating system"? especially with linux-distros coming with a pack of cd's it is hard to tell, if a library is a major component or not...

But you are right - it would be nice, if the CPL would allow the distribution of SWT-sources under LGPL.

Set Top Box GUI Kit Selection
GUI toolkits often lend themselves to certain application spaces based on their features. See QT and its various flavors. What are people using for Set Top Box GUIs? I've seen Espial Espresso as being designed specifically for the STB market. Any experiences with that product or STB GUI kits in general?

A different perspective.
The # of developers currently using any of these toolkits is tiny compared to the # of Windows C++ developers.

For example, the CodeProject site for Windows C++ developers has recently passed half a million registered users. Some of these developers are migrating to C#. Many of them don't really like MFC but they still like C++ and would prefer to not go to C#.

I hope that some of these developers will migrate to one of the cross-platform toolkits mentioned here. Unfortunately, most of them have never even heard of any of these toolkits. Instead they are migrating to another (unsupported) MS toolkit called WTL. (Now ain't that a wonderful combo: totally proprietary, but unsupported, only works on windows, and it could dissapear at any time.)

If you don't care about this, please don't flame me. Just stop reading. I do care and here's what I think is necessary to change this situation.

There needs to be a single, prominent, default C++ toolkit. There can still be lots of others, but one should be crowned king.

This toolkit must:

- be totally free. Qt is not an option. Windows developers are not going to abandon free toolkits for really expensive ones.

- use native widgets. Almost the whole target market for these developers is Windows users. They don't want a toolkit that uses GTK+ widgets on Windows (though personally I think GTK2 looks pretty good).

- exist now. If we start a design process on Boost now, and then eventually develop something it will be too late. Everyone will be using Java, C#, or VB by then.

This toolkit should:

- use modern C++. The developers who really like C++ want to use the STL, templates, exceptions, RTI, etc.

- become the basis for OOo. This would give it a higher profile and more users, not to mention all that code. (The OOo people are planning to move their code to a new GUI toolkit, by the way.)

But I guess I'm dreaming...

Re: What about Java?
% Finally, Java itself is not slow and
> does not use a lot of memory. It used
> to be at least 40x slower but now it's
> the speed of unoptimized C or better.
> Programs can even call overridden
> methods dynamically at runtime (ie,
> lookup method by string variable) at
> only 1/5th the speed of a static
> compiled call in C++. That's freakin
> unbelievable. And most 'hotspots' are
> actually optimized better than in C++.

You're right - that is freakin unbelievable, because almost none of it is supported by facts :-) Especially the parts about hotspots (sounds like you took that from a Sun brochure) and dynamic method invocation. You may (or may not?) have ran across a couple of selected benchmarks that seem to show that is the case with DMI, but take a look at the CPU cycles involved and you will see that this just doesn't make any sense, especially compared to a static call. I'd really like some links to the code on any benchmarks 'proving' this if you have it.

Heck, I've seen (expensive) non-GUI java apps. or parts thereof re-written in C++ not only because of direct execution speed, but also memory management and scalability problems - and yes, the Java runtimes were the latest and greatest from both Sun and IBM. Shocking but true - one of these apps. was re-written in VB 6 and out-performed the Java version. Also, bottleneck-prone parts of applications like database access have a loooong way to go to perform like their native counterparts no matter which runtime. Once I see best-of-class performing RDBMS's and OS's written from the ground up in Java, then I'll start to believe high-performance Java claims.

Check out: Linux Number Crunching (http://www.coyotegulch.com/reviews/almabench.html). I've done the same and other benchmarks with other C++ compilers vs. Java and while the Intel compiler is generally still the best, the other C++ compilers generally perform a bit better than GCC as well (so this article doesn't show just the best representitive examples for C/C++, although GCC is certainly good). I agree with the author's conclusion that "Java 1.4 is slow" - the benchmarks I've run seem to bare out that the Sun Java runtimes are getting slower with each release, probably as a results of attempts to fix other problems such as GC and scalability. Also, almost without exception from what I've seen, C/C++ compilers and libraries are still improving.

Also check out: The Petstore Revisited (http://www.middleware-company.com/j2eedotnetbench/) and download the report. People can go back and forth about how either or neither implementation was ideal, etc. but even more striking than the perf. results is the amount of effort that went into writing and optimizing the application between the two platforms.

You say java doesn't use a lot of memory and is not slow? Even compared to "bloated" Windows software, Java is an Intel stock-holders dream.

Java has a lot of nice features, but performance and scalability is not one of them, nor will it probably ever be compared to C/C++, due to the modular nature of C/C++ and the ability to code closer to the hardware.

> Most of the difficulty is due to the
> operating system fighting Java; if
> you've ever used Java on Mac OS X for
> instance you'll know how beautifully it
> integrates with the OS. A Mac user can
> just double-click on an executable JAR
> file (ZIP format) and they can just
> double-click and it runs like any other
> app, looks like any other app, and
> shares memory with other Java apps so it
> doesn't take many resources. On
> Windows, they have to install Java first
> and each Java app takes substantial
> resources. On Linux Java it's an even
> worse situation.

So now we are supposed to write OS's to conform to Java instead of the other way around??The "lowest common denominator" approach is precisely why Java will never be the best technical solution to most problems. May end-up being the best all-around cost-effective solution for really large scale apps. when portability is key, but in reality the twain shall rarely meet.

Re: What about Java?

> % Finally, Java itself is not slow and
> % does not use a lot of memory. It
> % used to be at least 40x slower but now
> % it's the speed of unoptimized C or better.
>
> % Programs can even call overridden
> % methods dynamically at runtime (ie,
> % lookup method by string variable) at
> % only 1/5th the speed of a static
> % compiled call in C++. That's freakin
> % unbelievable. And most 'hotspots' are
> % actually optimized better than in C++.
>
> You're right - that is freakin
> unbelievable, because almost none of it
> is supported by facts :-) Especially the
> parts about hotspots (sounds like you
> took that from a Sun brochure) and
> dynamic method invocation. You may (or

Check out some benchmark results:
benchmark results (http://groups.google.com/groups?selm=3C788DA3.A504AEF9%40verizon.net)

I ported these micro-benchmarks from C to Java. These show unoptimized C speeds for Java, and there was a non-aligned pointer bug in the Hotspot VM that slowed down the results for Intel (not AMD), so the actual results are better than this report.

> may not?) have ran across a couple of
> selected benchmarks that seem to show
> that is the case with DMI, but take a
> look at the CPU cycles involved and you
> will see that this just doesn't make any
> sense, especially compared to a static
> call. I'd really like some links to the

This isn't the appropriate forum for a lengthy technical discussion, but Hotspot is insane. It will re-write the code for method while it is executing. It'll dynamically 'inline' more methods at a time than C++ would ever dream of since it can throw the optimizations away when they are no longer used by the program. And so on. Often a method invocation will take fewer mechine instructions in Java than C++ due to better knowledge of actual types at the call site.

> code on any benchmarks 'proving' this if
> you have it.

...
> Check out: Linux Number Crunching.

What a crappy benchmark. The code quality is extremely poor, with unused variables all over the place and other variables used for multiple purposes. Most of the time in Java is spent in Math doing trig functions and much of the rest is in array access checks, so all you can really conclude is that Java is safer and may be slower at trig. Other than the bounds checks this micro-benchmark has nothing to do with Java as a language, and is contradicted by numerous other benchmarks.

Java has had excellent results doing real math, like linear algebra and FFT. Plus any benchmark showing C++ and FORTRAN as equivalent obviously is too simplistic to be an accurate indication of performance.

> Also check out: The Petstore Revisited
> and download the report.

Trying to conclude anything useful from Petstore is a waste of time.

> You say java doesn't use a lot of memory
> and is not slow? Even compared to
> "bloated" Windows software, Java is an
> Intel stock-holders dream.

Try it on a Mac. Ethereal on Windows is 10megs and the GUI lags so much with lots of data. You can do MUCH better than that in Java.

> Java has a lot of nice features, but
> performance and scalability is not one
> of them, nor will it probably ever be
> compared to C/C++, due to the modular
> nature of C/C++ and the ability to code
> closer to the hardware.

I agree that C/C++ will be slightly faster than Java, mostly due to stack-based objects. Of course, C/C++ programs will always crash, have buffer overflow bugs, have slower heap allocation, and be more time consuming to write.

> % Most of the difficulty is due to the
> % operating system fighting Java; if
> % you've ever used Java on Mac OS X for
> % instance you'll know how beautifully it
> % integrates with the OS.
>
> So now we are supposed to write OS's to
> conform to Java instead of the other way
> around??The "lowest common denominator"
> approach is precisely why Java will
> never be the best technical solution to
> most problems. May end-up being the best
> all-around cost-effective solution for
> really large scale apps. when
> portability is key, but in reality the
> twain shall rarely meet.

Nope. For example, Java has had the most advanced, feature-rich graphics pipeline on Windows and Linux for a long time. On an OS like Mac that co-operates with Java it is awesome. Lots of Linux evelopers have a tendency IMO toward complicated, stone-age stuff like C++ (and Xwindows for that matter) -- they think it's progress. Not exactly a fertile ground for Java.

Re: What about Java?

>
> Check out some benchmark results:
> benchmark results
>
> I ported these micro-benchmarks from C
> to Java. These show unoptimized C
> speeds for Java, and there was a
>

Thanks - I took a close look and two things jump out: One is that it seems you and the benchmark post are drawing some conclusions comparing de-optimized C code to other runtime systems. This is not valid because the added debug symbols and forced-order execution of the debug binaries, etc., etc. are both something that a compiler writer would never (consciously) create for a production executable. What I'm trying to say is that debug builds for any compiler / runtime are not valid for any benchmarking, because that is not what is distributed to an end-user but is for the consumption of the development tools and developer only - that's a well established standard for fair benchmarking. I don't know why the C debug-build times are even included in that post, unless the reason was to try and show that Java and Smalltalk can perform "OK" compared to a binary compiled for a debugger. Debug builds are intentionally "de-optimized" so the program flow can be better followed by a debugger, etc.

The 2nd thing that jumps out is that a normal (built for production) C/C++ binary is on average 2.3 times faster than the Java code. If you extrapolate that out to real-world software, that means for example an end-of-day process that runs for 8 hrs. with C/C++ would take 18.4 hrs. with Java, which would leave only 5.6 hrs. for a workday (I'd love a job with that company :-). Also, even considering processes like the short-lived micro-benchmarks in your link, a 2x difference in execution time on a busy machine can cause an exponential drop in scalability of the server as processes stack up in the FIFO column. And that is not even considering the extra resources that runtimes like Hotspot use on the server. The code analysis, JIT, optimization and generational GC that Java runtimes like Hotspot and the .NET runtime do is really pretty expensive in a high-use environment and that is always overlooked. Hotspot is a resource hog in a heavy-use environment. What does this have to do with client-side GUI toolkits? Nothing except to say that I think Java has been over-extended to be the end-all to application development so it is neither really scalable on the server nor really fast on the client.

>
> This isn't the appropriate forum for a
> lengthy technical discussion, but
> Hotspot is insane. It will re-write the
> code for method while it is executing.
> It'll dynamically 'inline' more methods
> at a time than C++ would ever dream of
> since it can throw the optimizations
> away when they are no longer used by the
> program. And so on. Often a method
> invocation will take fewer mechine
> instructions in Java than C++ due to
> better knowledge of actual types at the
> call site.

Again, this sounds like it's from the Sun site :-) Under almost all circumstances, the static C/C++ compiler will have as much info. to feed "inline" heuristics as the Java code at runtime, plus it will have a lot more time to (reasonably) use this info. The major areas that a dynamic execution system may have an advantage are things like it will better know how much memory has been allocated for an object or collection of objects, and also the normal conditional path flow of the program. So what end's up happening is that more things in the C/C++ code is optimized than needs to be under normal program flow, but the upside is it is well optimized for all program flows.

>
> % code on any benchmarks 'proving' this
> if
> % you have it.
>
> ...
> % Check out: Linux Number Crunching.
>
>
> What a crappy benchmark. The code
> quality is extremely poor, with unused
> variables all over the place and other
> variables used for multiple purposes.
> Most of the time in Java is spent in
> Math doing trig functions and much of
> the rest is in array access checks, so

Extremely poor?? I only found two unused vars. (32 bit integers), and so did the compiler. Like it or not, most time spent in many programs is calling library functions and accessing arrays, so this is a pretty valid benchmark as far as they go.

>
> Java has had excellent results doing
> real math, like linear algebra and FFT.
> Plus any benchmark showing C++ and
> FORTRAN as equivalent obviously is too
> simplistic to be an accurate indication
> of performance.

Well, I don't agree there. There are many areas in which C/C++ can hold it's own with Fortran, and that includes some often used mathematical stuff, even stuff that includes large matrices and math library calls. For example, depending on the circumstances, it's possible to layout large arrays and manipulate them with the C/C++ memory functions better than you can with the array handling built-in to Fortran (or Java for that matter). Besides, based on the results I've seen, the Intel Fortran system is very good and so is their C/C++ system.

> % Also check out: The Petstore
> Revisited
> % and download the report.
>
> Trying to conclude anything useful from
> Petstore is a waste of time.

No it isn't, for 3 reasons. The people who chose Petstore were Java biased in the first place (Java is where that company makes it's money) and initiated the 2nd comparison. The second reason is that the .NET and Java apps. were functionally equivalent. The third is that the .NET system ran quite a bit faster and was a lot more scalable on the same hardware than both Java systems with a lot fewer lines of code and much less time spent optimizing the code for either Java runtime. It is very significant that the lower cost and easier to maintain system can come out on top performance-wise for a functionally equivalent application where the sponser's hypothesis was disproved (according to their paper, the sponser set out to prove that Java would be the performance leader if optimized properly).

The reason I'm responding to all this is because you stated that C/C++ GUI toolkits are no longer relevant given Java performance and that is wrong given the the scads of "real-world" evidence as well as benchmarks.

I'd be a fool to ignore the usefulness of Java and I think it would be equally foolish to say there isn't a place at the table for cross-platform C/C++ GUI toolkits because of Java performance.

Re: What about Java?

>
> %
> % Check out some benchmark results:
> % benchmark results
>
> Thanks - I took a close look and two
> things jump out: One is that it seems
> you and the benchmark post are drawing
> some conclusions comparing de-optimized
> C code to other runtime systems.

Comparing to debug build shows that Java is well within the same ballpark as C.

> What I'm trying
> to say is that debug builds for any
> compiler / runtime are not valid for any
> benchmarking, because that is not what
> is distributed to an end-user but is for
> the consumption of the development tools
> and developer only - that's a well
> established standard for fair
> benchmarking.

In Java you don't have separate "debug builds" or build for specific processors. Java generates processor instructions relavent to your processor at runtime so you don't need X different "builds" for different processor versions -- that's for stone age languages.

> The 2nd thing that jumps out is that a
> normal (built for production) C/C++
> binary is on average 2.3 times faster
> than the Java code.

Those numbers compare Microsoft's VC++ to Java, and Java is doing array bounds checking. And the IBM JVM seems to be ~1.8x faster than Sun's for this type of computation, making it very close in speed to a C++ compiler were LOTS of resources have been put into maximum performance.

> What does this
> have to do with client-side GUI
> toolkits? Nothing except to say that I
> think Java has been over-extended to be
> the end-all to application development
> so it is neither really scalable on the
> server nor really fast on the client.

If 1.2x or even 2x slower is not an acceptable performance loss for getting an easy to use, safe language with huge, quality class library for programs that spend most of their time idle waiting for user input then what's the point in logic and reasoning? You have to use it.

> % [Why hotspot is awesome.]
%
> Again, this sounds like it's from the
> Sun site :-)

So download the hotspot VM source code and look at it. It's true, whether you want to believe it or not.

> Under almost all
> circumstances, the static C/C++ compiler
> will have as much info. to feed "inline"
> heuristics as the Java code at runtime
> plus it will have a lot more time to
> (reasonably) use this info. [...]

You should read up more on hotspot and runtime optimizations.

Re: What about Java?
% Comparing to debug build shows that Java
> is well within the same ballpark as C.

No, it doesn't - it's apples to oranges. It's akin to comparing bytecode to JIT for Java, because the debug build is basically built to be interpreted by the debugging system. Sun's jdb debugs the *bytecode*, not the native code put out by the runtime - there's a more direct comparison.

> In Java you don't have separate "debug
> builds" or build for specific
> processors. Java generates processor

Yes, and that is one of the downfalls of trying to debug Java apps. That's why Java's turned from "Write once run anywhere" to "Write once, debug everywhere and then tweak for OS X. Oh and while you're at it, try a different runtime and fiddle with the runtime switches too."

> Those numbers compare Microsoft's VC++
> to Java, and Java is doing array bounds
> checking. And the IBM JVM seems to be
> ~1.8x faster than Sun's for this type of
> computation, making it very close in
> speed to a C++ compiler were LOTS of
> resources have been put into maximum
> performance.

IBM is throwing everything they've got at their Java runtimes and also for the sake of clarity,
those numbers compare VC++ 6, not 7 or 7.1, the Intel compiler or GCC 3.3. Can't say for sure about GCC 3.3, but I know the latest iterations of the MS and Intel compilers produce faster code than their predecessors, in most benchmarks at least. Your test was done with JRE 1.3 which post-dates Microsoft VC 7. And the Sun JRE 1.3 is actually faster than Sun JRE 1.4 for most of the benchmarks I've seen and done myself - same with IBM 1.3 vs. 1.4 on Linux. I'm sure the new StrictMath requirements for Java have something to do with the slowdown, but also I think (and have picked up elsewhere) it's because the earlier Java optimizers were optimizing away valid code in some cases.

>
> If 1.2x or even 2x slower is not an
> acceptable performance loss for getting
> an easy to use, safe language with huge,
> quality class library for programs that
> spend most of their time idle waiting
> for user input then what's the point in
> logic and reasoning? You have to use
> it.

Like I said in my previous post, I'd be foolish to ignore all that and I'm not, but I would have to qualify "easy-to-use" and "quality" a bit: Most of the C++ GUI toolkits in this article are as straight-forward to use as Swing and are certainly as high in quality. Which brings me back to the original reason I posted - It would be equally foolish to stop using and improving C++ or C++ tools just because Java is out there.

> You should read up more on hotspot and
> runtime optimizations.

If Hotspot is so technologically superior, why is IBM taking it to the cleaners on a lot of numerical stuff? :-) I have read-up on Hotspot to try and figure out if the marketing hype was blowing smoke and sure enough they were IMHO. Once again, the static C/C++ compilers will have almost of the same info. available at compile time as Hotspot will at runtime wrt inline opimizations, except for some program flow and mem. info. Plus, the C/C++ binary will not be continuously using system resources at runtime to accomplish it's optimizations.

>

Re: What about Java?

> If Hotspot is so technologically
> superior, why is IBM taking it to the
> cleaners on a lot of numerical stuff?
> :-)

The benchmarks cited don't even test hotspot-specific features (such as dynamic inlining) at all. Read the Hotspot benchmarking FAQ.

> I have read-up on Hotspot to try and
> figure out if the marketing hype was
> blowing smoke and sure enough they were
> IMHO.

Look you don't have to like Java, but you opinions are obviously based on an unfortunate combination of outdated information, lack of information, and questionable reasoning. Go download the Hotspot VM source code if you want the proof -- it's in C so you should have no trouble following it.

It's not like C/C++ doesn't have performance advantages because of value types and mass-allocation, but most of the things you've said wrt Java in these posts is incorrect.

Re: Gtk+ and Gtkmm are GNU LGPL

> I prefer the model where you can do Free
> Software for free
> but have to reward those that give their
> work to you when
> you are using them to make money (Qt)

Well, the problem with this is, that it forces me to learn a tool for "commerical" and one tool for "free" development.

Which is not nice.

A thing that was not mentioned at all is, that QSA is not usuable at all; not from a technical point of view, but from a legal one. Trolltech insists that QSA scripts cannnot be used to develop new functionality/access the Qt APIs, or else every user needs a Qt developer license.

While I understand that this is needed to prevent somebody releasing a "Qt Programming Environment" program, but it has already killed QSA on two commericial projects I've been part of this year ;)

yacc

"Raymond's Jargon File"

I don't mean to flame, but i would like to correct a common mistake.

Jargon File is NOT ESR's. It is maitained by him.

My sensitivity on the subject is against the common perception on masterpieces. There ARE some community works in existence. :)

http://www.hemmerling.com/html/en/framwork.html
Hello !

For my own resarch, and thank to the help of the infos found on this page, I setup a web page with links to all frameworks, with focus on C++ and Java frameworks for GUI, network and database building

http://www.hemmerling.com/html/en/framwork.html

Sincerely
Rolf

Re: A different perspective.
Borland released an IDE for the wxwindows toolkit. Linux, Solaris,... are supported. This is a boon IMO.

C++BuilderX Personal Edition:
Release Date: 10/07/2003

Re: What about Java?

> Um.....Or the fact that
> the Swing looks like crap?

Please check this Java app out than.

http://www.jgoodies.com/freeware/jdiskreport/screenshots.html

I think those are one of the most beautiful looks I even seen in development without ANY cost or needed knowledge from a developer.

I used to think java was lacking alot on GUI but after seen some good skins (look&feel) I had to change my mind.

Re: A different perspective.

>
>
> There needs to be a single, prominent,
> default C++ toolkit. There can still be
> lots of others, but one should be
> crowned king.
>
> This toolkit must:
>
> - be totally free. Qt is not an option.
> Windows developers are not going to
> abandon free toolkits for really
> expensive ones.
>
> - use native widgets. Almost the whole
> target market for these developers is
> Windows users. They don't want a
> toolkit that uses GTK+ widgets on
> Windows (though personally I think GTK2
> looks pretty good).
>
> - exist now. If we start a design
> process on Boost now, and then
> eventually develop something it will be
> too late. Everyone will be using Java,
> C#, or VB by then.
>
> This toolkit should:
>
> - use modern C++. The developers who
> really like C++ want to use the STL,
> templates, exceptions, RTI, etc.
>
> - become the basis for OOo. This would
> give it a higher profile and more users,
> not to mention all that code. (The OOo
> people are planning to move their code
> to a new GUI toolkit, by the way.)
>
> But I guess I'm dreaming...

Nope. You should check out the Visual Component Framework (http://vcf.sourceforge.net). It does everything you list here. It's easy to use. It works great on Win32, and there's an active port underway for OSX. The linux port is kind stagnant, but if we get more help that could change.

The framework uses modern C++, RTTI, plus advanced reflection features that are on par with Java's Reflection API. Makes heavy use of STL, supports Unicode internally, Locale support, native widget support and graphics API's for drawing all the basic visual components, it's free and has a BSD license.

TCL Graphics
I have been a programmer for 15 Years now. The languages I use are: C++, C and Java. Out of the scripting languages I have used Perl. I really was not very happy with its mix of grammar, nomenclature and vagueness. Out of curiosity I picked up a book written for TCL/TK. I was amazed how organized TLC's syntax is. I am also taken back on how solid the programming structure is from package to package throughout. And last but not least how easy it is read TCL code. What's even more amazing is that in one week I was able to develop a tool that has upgraded over 2000 devices in about two hours. And what's funny about that is, the enterprise commercial equivalent could not even come close to the features built into the tool I wrote in "TCL/TK". The TCL project started on a Monday morning and was complete in one week. Please understand I am not bashing Perl. Thanks to PERL the competition is stiff. But I have to admit I have been able to turn more people on to TCL and get them up and running in less time than with PERL. Others like me in experience and some with much less programming experience. And as far as the graphics is concerned, no one new it was a TCL script. They thought it was bonafide Windows program. Oh well that's it for me, for now.

Re: Breaking out of the Box

> It has
> non-rectangular buttons
> with shaped borders that highlight on
> use, it plays a
> sound file on use,

could something like this be implemented as an "accessibility" skin to an existing toolkit?

Re: What about Java?

>
> I just don't understand why Linux / Open
> Source programmers would rather spend
> lots of extra time and effort hacking
> out a GUI in C or C++. I used to
> program directly to Xlib, and I feel the
> same way as the toolkit users who would
> feel sorry for somebody using straight
> Xlib.
>
> With Java you get a simple and powerful
> API for creating UIs. You get more
> advanced graphics features than pretty
> much everything out there (anti-aliased
> everything, real transforms, geometry,
> alpha/composites, extremely optimized
> pipeline, pluggable look and feels,
> event-based callbacks, automatic pacing
> and coalescing of repaints,
> internationalization, etc).
>
> And then you get other Java benefits
> like working on every operation system,
> reflection, garbage collection,
> weak/soft references, huge library of
> useful stuff like zip, regex, crypto,
> XML, etc.
>
> Finally, Java itself is not slow and
> does not use a lot of memory. It used
> to be at least 40x slower but now it's
> the speed of unoptimized C or better.
> Programs can even call overridden
> methods dynamically at runtime (ie,
> lookup method by string variable) at
> only 1/5th the speed of a static
> compiled call in C++. That's freakin
> unbelievable. And most 'hotspots' are
> actually optimized better than in C++.
>
> Compared to other toolkits, Swing (the
> UI part of Java) starts up slowly and
> uses a lot of memory (it was designed by
> former Smalltalk people...). But once
> it's up and running it's fast and
> doesn't use much extra memory. So it
> isn't suitable for simple applications
> for that reason, but for medium or large
> ones it's an excellent choice
> technically speaking.
>
> Most of the difficulty is due to the
> operating system fighting Java; if
> you've ever used Java on Mac OS X for
> instance you'll know how beautifully it
> integrates with the OS. A Mac user can
> just double-click on an executable JAR
> file (ZIP format) and they can just
> double-click and it runs like any other
> app, looks like any other app, and
> shares memory with other Java apps so it
> doesn't take many resources. On
> Windows, they have to install Java first
> and each Java app takes substantial
> resources. On Linux Java it's an even
> worse situation.
>
>

Really? I dont think so. Anybody that has ever used a non-trivial Java program or has programmed in Java knows that Java is slower than native programs written in C++. This is a fact of life, something that we accept when we use Java.

Re: What about Java?

>
> % Um.....Or the fact that
> % the Swing looks like crap?
>
> Please check this Java app out than.
>
> http://www.jgoodies.com/freeware/jdiskreport/screenshots.html
>
> I think those are one of the most
> beautiful looks I even seen in
> development without ANY cost or needed
> knowledge from a developer.
>
> I used to think java was lacking alot on
> GUI but after seen some good skins
> (look&feel) I had to change my mind.
%
>

People who claim that Java can be as fast as C++ or even faster often base their opinion on the idea that more disciplined languages give the compiler more room for optimization. So, unless you are going to hand-optimize the whole program, the compiler will do a better job overall.

This is true. Fortran still kicks C++'s ass in numeric computing because it is more disciplined. With no fear of pointer aliasing the compiler can optimize better. The only way that C++ can rival the speed of Fortran is with a cleverly designed active library like Blitz++.

However, in order to achieve overall results like that, the language must be designed to give the compiler room for optimization. Unfortunately, Java was not designed that way. So no matter how smart the compilers get, Java will never approach the speed of C++.

Re: TCL Graphics
I have never used TCL/TK, but I have heard it said on many occasions that the syntax for TCL is rather strange. I personally prefer Python - it is clean, object oriented, and has bindings for many GUI toolkits.

GTK and Windows stability
Just wanted to point out that since this article was written, the stability of the Win32 port of GTK has been greatly improved, and I would say it is now on the same level as the UNIX versions. Combined with wimp (a theme for Windows), GTK looks very much like native Windows widgets. I would also say that mingw + GTK is probably one of the easier development environments to get working correctly in Windows, thanks to the pkg-config utility provided with GTK, which takes care of providing the proper include and lib parameters to the compiler.

In regards to . . .
I would say flexibility is the biggest advantage and as a programmer sid (http://www.shroff.us), Xlib allows more freedom and flexibility.

tcl/tk

I can't agree with the statement that tk is at the same level of complexity and abstraction as xlib. Tk is MUCH simpler and higher level than xlib. I'm probably in an almost ideal position to judge. At one time I did a great deal of programming in raw xlib. For about ten years I then did next to no graphics programming. What little I did was updating old xlib code. A couple of years ago I returned to doing graphics programing and decided to try tcl/tk. I have since written several fairly complex programs in tcl/tk. I've also done a couple of minor projects using tkinter with python.

I was simply stunned with how much easier and faster it is to write in tcl/tk than in C/xlib. Some of that is of course due to tcl being much higher level than C, but it is also true that it took me a while to get used to tcl and that I was already very familiar with C when I was using raw xlib, so I don't think that that is the major factor. Tk takes care of all sorts of details that you have to deal with in xlib.

Let me also make a comment on tcl since some people have said that it has a weird and inconsistent syntax. I don't agree. The problem at first, for experienced programmers, is that tcl has an unfamiliar
syntax, one that is simpler than that of most other languages. Ironically, the syntax is probably more of a problem for experienced programmers than for novices; we're more set in our ways. Tcl syntax is actually rather like that of lisp. Indeed, the thing that bothers me most about Tcl syntax now that I'm familiar with it is the way comments are handled, which limits where you can put them. That's also a problem with many versions of lisp, though for a different reason.

Many thanx!!!
Many thanx!!! Very useful article!!!

Re: Many thanx!!!

> Many thanx!!! Very useful article!!!

Same thoughts. But it will be so much greater if it's updated.

Tabular Comparison
I would love it if someone could update this atricle with a tabular summary, including various criteria that affects performance and portability. It will be great if a glossary can be included as well (for the criteria, example: blocking or non-blocking main loop - what does that mean). Including the glossary will be particularly helpful for newbie developers who are stepping into the free world.

Other things like language compatibility, language feature utilisation, learning curve, etc will be really helpful.