GUI Toolkits for The X Window System
 by Leslie Polzer, in Category Reviews - Sun, Jul 27th 2003 00:00 UTC

This article is aimed at Unix developers who already have some experience with programming languages and want to start developing GUI applications (mainly for The X Window System, though portability is discussed). It may also come in handy if you have used a particular GUI toolkit for some time and want to know whether others might suit your needs better. The main focus is comparison and introduction, but it serves as a bit of tutorial, as well.

Why Do We Need Toolkits?

There are two significant answers to this question:

1. The Xlib API is hard to use because...
   • ... its function calls bloat the code and limit readability.
     (By the way, did you know that the function prototypes are still K&R style? Ugh!)
   • ... the color handling is awful.
     (Now you know why most applications that come with X are 1 bit colored.)
2. Portability. It must be pure hell to port Xlib code to Microsoft Windows or the Linux DirectFB.

Possible reasons for not choosing a toolkit are easily refuted. We'll take a look at three of them:

1. Money: All of the toolkits mentioned here can be used free of charge (Qt only for non-commercial applications, though). Even if they couldn't, the time saved would make up for the initial cost.
2. Performance: I was unsure myself whether the use of a toolkit would yield a performance penalty, and therefore collected some information regarding this issue. My research shows that the overhead caused by the additional far jumps (read: function calls) is negligible for all but the most critical applications (at least with GTK's drawing library, GDK; see "Timing analysis of Xlib and GDK"). Even there, I don't think that this is a problem with today's CPUs and graphics cards.
3. Flexibility: One could say that we're giving up flexibility by not using the most primitive functions. Most toolkits just remove the fuss of dealing with Xlib; I can't think of any case in which Xlib would give the programmer more freedom than a toolkit does. And if you pay attention to the fact that most toolkits are organized in an object-oriented fashion, which also means (multiple) inheritance, you will see that this argument certifies Xlib as a disadvantage instead of an advantage.

Synopsis

Below, I offer a guide to various toolkits for POSIX-based systems which can be used free of charge: GTK+/gtkmm, Trolltech Qt, FOX Toolkit, FLTK, and wxWindows. It will start with some general information about the concepts of GUI programming, so beginners will have a better chance of understanding the code examples I provide. All toolkits will mainly be examined in terms of maturity (which means stability), popularity (which popular applications/how many applications use this toolkit?), accessibility and internationalization support, portability, language bindings, extensibility, licensing conditions, and documentation. The core of each toolkit's information is written in continuous English sentences, but a spotlight on the specific properties follows each section.

Please note that I won't cover Motif/Lesstif in this article because it is similar to Xlib in terms of age and complexity. Tcl/Tk isn't much better. If you feel a specific toolkit should be mentioned here, drop me an email.

Terminology

Widget:

From Eric S. Raymond's "Jargon File":

"[...] [poss. evoking 'window gadget'] A user interface object in X graphical user interfaces."

So what exactly is a widget by example? A button you can click on, a value slider you can slide around, a window, checkboxes, radio buttons... The term "widget" is used with most toolkits (also on Win32) nowadays as a generic name for these objects.

Main Loop, GUI Loop, Main Event Loop:

Most, if not all GUI toolkits, be they in C or C++, have this. The main loop waits for user input and controls various other things (depending on the toolkit).

Event:

An event is something coming from the outside, maybe a resize event sent by the operating system so the application can take actions to rearrange its graphical interface elements. An event can also be induced by the user, e.g., a mouse click. (This last is X terminology. I think that on Win32, "event" does not refer to user actions.)

Callback:

A callback can be an ordinary C function or a C++ member function if the GUI system supports functors. Callbacks are often used to handle user input; a click on a button may call the callback function on_button_click(widget* w, int but_num).

Signal/Slot:

These two belong together and can be used for communication between objects: Object A sends a specific signal which is caught by object B because the latter has a slot for it. A slot is a callback for a signal.

Dynamic Layout:

Think of a user resizing the window. When the coordinates of a widget are fixed X/Y pixel coordinates (Xlib, Win32 native API), the widgets will resize not at all, incorrectly, or only with a lot of code overhead. Dynamic layout is achieved by using logical objects instead of coordinates.

Rapid Application Development (RAD):

RAD describes techniques that aid the programmer in a way that enables him to concentrate on the core of the application he is writing. Most important RAD tools are GUI builders which offer a point-and-click interface for tasks like widget placement or callback definitions. RAD tools also include, for example, makefile generators.

The Toolkits Themselves

GTK+ and gtkmm

"GTK" is the abbreviation for "The GIMP Toolkit", which was originally developed for the popular 2D graphics application "The GIMP" (for more information on the history of GTK+, see The GTK+ FAQ, sections 1.2ff). Since then, it has evolved into a large collaborative project. The current major version of GTK+ is 2, and it introduces (in comparison with the old 1.2 series) some new and enhanced widgets, better internationalized input support, speed improvements, and a lot of API changes, along with all the resulting incompatibilities. GTK+ itself is written in pure C using an object-oriented approach, special types, and casts. There is, however, a C++ wrapper library called "gtkmm" (formerly GTK--), which reacts very quickly to changes in the underlying GTK+ code and offers developers a very good C++ API. The fact that there exists a plain C API and numerous language bindings attracts a lot of developers and is responsible for the toolkit's great popularity. gtkmm adds C++'s syntactical sugar and built-in object-orientation features. Thanks to its well-defined interface, very structured and clean programming is possible.

GTK+ 2 supports Unicode natively; translation is not integrated and must be done with GNU gettext or another tool or technique of your choice. Some important things are not present in the GTK+ distribution, such as support for OpenGL. This is a design decision by the GTK+/gtkmm development teams, resulting in a very modular approach, so that you have, in this example, the choice between GtkGLArea, a widget that serves as a GL viewport (beware: the homepage is dead, the current version doesn't compile), and GtkGLExt and its C++ wrapper gtkglextmm, which integrates seamlessly with gtkmm. (The gtkglext packages provide the ability to use OpenGL code on any widget.) The same is true for network functionality, document/view, and many other features.

Overview of GTK+

Full Name	GTK+ -- GIMP Toolkit
Web site	http://www.gtk.org/
Programming Language	C / C++ with gtkmm
Language Bindings (AKA wrappers)	Many, see the official list
License	GNU LGPL
Portability	Win32, DirectFB, BeOS
Themable	Yes (GTK+ themes @ freshmeat)
RAD	Yes (mainly with Glade; some others available)
Documentation	Comprehensive reference (most of the time behind the current API, though), tutorials
Extensibility	GTK+: with plain C OOP; gtkmm: standard C++ inheritance
Strengths & Features	Internationalization features: many input methods available, right-to-left support, Unicode strings gtkmm: objects live in well-defined namespaces gtkmm: well-defined, clean, and modular API Markup support with font rendering
Weaknesses	Win32 port unstable
Notes	Uses GNU gettext for translations

Trolltech Qt

Qt is the next big GUI package I'd like to discuss here. In terms of size and functionality, it is probably next to GTK+. The popular major versions of Qt are 2 and 3, and both are written in C++ with the addition of a precompiler pass involving a special program from Trolltech, the "Meta Object Compiler", or "MOC". It meddles with Trolltech's C++ extensions (such as arbitrary class information like name and author or signal/slot capabilities for each class), things that C++, RTTI, and gtkmm with its libsigc++ provide. The problem with Qt is that it was written with early C++ compilers in mind which didn't offer the capabilities Trolltech needed for their GUI toolkit, and today, one has to work with the slack. There is also another precompiler called "User Interface Compiler", or "UIC". It must be invoked if you use the integrated RAD environment QtDesigner. QtDesigner saves its files in XML format; UIC converts them to C++ source. These additional build steps can, of course, be integrated into the project's Makefile (there are examples of how to do this in Qt's manual), so I don't think of it as a negative thing. Documentation in HTML format and man pages comes with the Qt source tree, and a PDF version is available for download. There is also an application for browsing the documentation ("QtAssistant"). Unfortunately, I couldn't get it to work... No matter, my browser does just as well (though without a global search feature).

Before I continue discussing the technical aspects of Qt, I will discuss the license issues that caused a lot of disturbance and uncertainty in the Open Source community. What you get when you download Qt 2/3 is the free X11 version ("Qt Free Edition") which enables you to write non-commercial applications for The X Window System. When you want to create commercial, proprietary, or non-free software, or want to compile your program for Windows or embedded systems, you'll have to pay for the Qt Professional or Enterprise version (both are quite expensive). Qt tried to specify this in their own license (the "QPL") because they felt the GPL could cause them some problems (please see freshmeat article #180 for more information). From Qt 2.2 and upwards, you can now freely choose between the QPL and GPL before building the libraries. That's the whole story; if you feel I missed an important point, feel free to correct me (Qt flames go straight to /dev/null, though). You can read more about Trolltech's licensing issues in freshmeat articles #170, #172, and the one mentioned above.

Back to tech. Along with QtDesigner and QtAssistant, Trolltech bundles even more useful applications with the Qt package: There is QtLinguist for easy editing of translation packages, qembed, a tool to convert many different sorts of data to embedded C code, and qmake, a portable Make utility with special support for Qt. QtDesigner offers, in addition to its basic functionality, wizards to help you get started. Widgets and predefined dialogs have, by default, a look very similar to Microsoft Windows. It is fully themable, though, so at least the colors can be changed. The internationalization capabilities are quite excellent. There is the tool mentioned above (QtLinguist), support for argument strings (think of printf() without the disadvantages), and Unicode support. A string class and various other convenient STL stuff is also included, so you don't have to use STL in your project.

I feel that Qt's weaknesses lie not in its technical aspect, but in Trolltech's general attitude towards the end user. Trolltech says they wanted to create, among other things, a free toolkit for developers of Free Software. They succeeded, and Qt-X11 is a very good product used by many applications, the most prominent being KDE. But when you look at their Web site, you'll see a lot of business talk and praises reminding me of a market place. And what if you want to port your program to Windows? No problem if you have $1,550; for this price, you get the professional version of Qt. The Macintosh and Embedded versions are free, though. I can't help it, but the real Free Software community feeling doesn't well up on my side. This should not stop you from choosing Qt if it fits your needs, though; it is a toolkit like the others presented here, with its own strengths and weaknesses. I'll get back to Qt and "fitting your needs" in the summary.

Overview of Qt

Full Name	Trolltech Qt
Web site	http://www.trolltech.com/
Programming Language	C++ with special pre-compilers ("MOC", "UIC")
Language Bindings (AKA wrappers)	Perl, PHP, Python
License	Trolltech QPL or GNU GPL at your will
Portability	Win32, MacOS, Embedded Devices, Linux Framebuffer
Themable	Yes
RAD	Yes (Bundled Qt Designer)
Documentation	Comprehensive reference, tutorials
Extensibility	Plug-In interface for some base widget types
Strengths & Features	Integrated internationalization and translation features and programs to help with internationalization Many helpful tools bundled RAD tool offers nice wizards Many advanced widgets bundled
Weaknesses	Very business-oriented main Web site Main branch depending on one company Commercial developers and people wanting portability have to pay Huge sources and binaries, library itself takes ages to compile Objects not referred by namespace but simple literal prefix "Q"
Notes	Slow FTP server Needs special precompiler pass ("MOC", "UIC" with RAD) Dominant Microsoft Windows look

Fast, Light Tool Kit (FLTK)

FLTK is the C++ successor to the XForms library (which is written in plain C), so I won't cover the latter here. XForms is not Free Software and is free of charge only for non-commercial use. FLTK's strength lies, as its name suggests, in its size and speed. The abstract base class for widgets is 60 bytes, and a statically linked and stripped "hello world" is ~80kb. FLTK code is carefully organized and offers the linker a lot of opportunities to leave unused code out. The basic widget types have many variants, some of which are quite innovative and beautiful. FLTK's main loop (which waits for and processes user events) is non-blocking; FLTK must be instructed explicitly to wait for events. While FLTK lacks precomposed dialogs, it offers a very optimized and direct interface to OpenGL, and a compatibility header file for GLUT is included. In my opinion, this is a very good base for getting started with 3D programming. The toolkit is also, in general terms, very friendly to beginners, and is easily understood.

One thing you have to get used to is the quite unique (yes, that word again; FLTK has some things not found in the other toolkits) method of getting and setting widget attributes. You may be used to things like Object::set_attribute() and Object::get_attribute(). The approach used by FLTK is to leave out the "get_"/"set_", and just write Object::attribute() and act according to the context. If the attribute accessor function is called in a context implying a void return type, the "set" function is called. When a return value is demanded, the "get" function, which is declared constant, is executed. This has positive and negative sides; you have to type less when dealing with attributes, but the code is (arguably) less readable.

FLTK doesn't have to hide when it comes to RAD, either. Its RAD tool, "FLUID", containing every widget the FLTK library supports, is a mere ~350kb statically linked, outputs C++ code, and is, like the rest of the FLTK library, efficient and not overloaded.

It should be noted that FLTK's internationalization capabilities are limited. While it supports composition of accented characters, it uses ordinary char arrays for string handling. Capabilities beyond that depend on the underlying operating system or external libraries (which may, of course, be a positive thing if speed and size do matter to you). It must be stated, therefore, that FLTK programs are quite easily (with the help of GNU gettext) internationalized for a certain bunch of languages. When it gets to things like right-to-left input or characters requiring Unicode, it gets complicated.

Still, I couldn't find any real weaknesses. FLTK does an excellent job of meeting its design goals. It's fast, light, flexible, and easy to use.

Overview of FLTK

Full Name	FLTK -- Fast, Light Toolkit
Web site	http://www.fltk.org/
Programming Language	C++
Language Bindings (AKA wrappers)	Lua, Perl, Python
License	GNU LGPL
Portability	Win32
Themable	Yes
RAD	Yes ("FLUID")
Documentation	Comprehensive reference, tutorials
Extensibility	Standard C++ inheritance
Strengths & Features	Very small memory footprint, throughly optimized Programming is very straightforward Direct OpenGL support; portable GLUT header file Main loop non-blocking
Weaknesses	Widgets not referred by namespace but simple literal prefix "Fl_"; functions and enums are, though
Notes	Internationalization issues not handled by FLTK; depends on OS Uses return type overloading for differentiation of get/set methods.

wxWindows

wxWindows is a giant among GUI toolkits. The documentation section reflects the size and functionality of the whole toolkit quite well, and it's not small. It is a very well-designed toolkit with portability and features in mind. In the number of language bindings, it is only surpassed by GTK+, its RAD tools are innumerable, and there's even an OS/2 port. The wxWindows team is especially proud that its toolkit is one of the most advanced and mature ones. They're right; its history starts in 1992. Despite these facts, it is not very well known. That might change in the near future, as wxPython (for example) is getting more and more happy developers, and wxWindows developers are zealous when it comes to GUI toolkits.

The core of wxWindows is rock solid. Only 10% of its functions are non-portable OS-specific drawing functions, and so it claims to be a kind of "written once, running anywhere" toolkit, like FOX. There's also a version that sits atop GTK+, so it can be seen as an addition and simplification of the toolkit level GTK+ is on. With this in mind, one can see that wxWindows adds many convenient features. A built-in configuration file API saves a lot of work that most applications require, and the same goes for printing support. Resource files in XML format ensure optimum portability, and the integrated HTML class makes reports, text formatting, and a help viewer a piece of cake. Its position among the other toolkits is discussed in the summary.

Overview of wxWindows

Full Name	wxWindows -- Cross-platform GUI library
Web site	http://www.wxwindows.org/
Programming Language	C++
Language Bindings (AKA wrappers)	BASIC, Eiffel, Java, Javascript, Lua, Perl, Python
License	wxWindows License (GNU GPL compatible)
Portability	Win32, MacOS, OS/2, Embedded Devices
Themable	No
RAD	Yes, many tools available; for example with wxPython: Boa Constructor
Documentation	Very comprehensive
Extensibility	Standard C++ inheritance
Strengths & Features	Very advanced, mature, and portable Uses native widgets if possible, provides fallbacks if not Supports XML resource files Built-in configuration manager Built-in printing support (generates Postscript on X) Integrated OpenGL, HTML, Networking
Weaknesses	Some things done with macros Not themable Not exception-safe Objects not referred by namespace but simple literal prefix "wx"
Notes

FOX Toolkit

The FOX toolkit is, in terms of features and portability, probably next to wxWindows, but it introduces some interesting concepts and occasionally obscures things which could be straightforward. For example, it requires you to call the FX_DECLARE macro in the declaration of a class derived from an FX object. This may result in less typing, but also in less clarity, and exchanging clarity for brevity is something I'm not very fond of. Or take the message ID handling: The documentation tells the developer to use an enum and fiddle around with FOX's private message IDs. 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?"

Enough ranting. After all, FOX has some really fine features to offer! For example, its messaging system: All FOX objects can send messages to each other and receive all kinds of events. Message forwarding is also possible, and automatic updating of GUI elements according to specified conditions in the application. What FOX does here is basically take the functionality of gtkmm's libsigc++ and add a lot of predefined stuff to it. This may be complicated, but is also very convenient. Easy incorporation of outside events (like incoming data via a pipe or signals) is also possible with FOX. Data targets provide an excellent interface between data and widgets, again taking tedious chores away from you. Last but not least, FOX comes with its own regular expression class, which might come in handy. All in all, FOX can be a very powerful, comfortable, and portable toolkit once you get used to its syntax (and do better OO than the documentation's examples).

Overview of FOX Toolkit

Full Name	FOX Toolkit
Web site	http://www.fox-toolkit.org/
Programming Language	C++
Language Bindings (AKA wrappers)	Eiffel, Python, Ruby
License	GNU LGPL
Portability	Win32, Mac (with OS X + XFree or Apple X Server)
Themable	No
RAD	Work in progress
Documentation	Comprehensive, but structured like a collection of HOWTOs; Doxygen-style reference docs would be great (note: there is a link to an unofficial "Class Index" page, but it was dead when I visited the site)
Extensibility	Standard C++ inheritance
Strengths & Features	Sophisticated target/message system Built-in regular expression support "FXRex" Built-in configuration manager Direct OpenGL support
Weaknesses	API at times quite hackish and immature (macros) Objects not referred by namespace but simple literal prefix "FX"
Notes

Summary

All of the toolkits mentioned have quality reference documentation with tutorials and a comprehensive hyperlinked API reference. All of them have wrappers for other languages, with C++ still the most structured and fastest of all (though scripting languages are easier to program with). Speaking of C++, all the toolkits but gtkmm neglect the fact that C++ has a very useful feature called "namespaces". Instead of using namespaces, they add a prefix to their functions and classes. A good feature they all have is dynamic layout; none of them relies on pure Cartesian pixel coordinates, although it is possible to arrange widgets with them in this way. Two toolkits, wxWindows and FOX, rely on preprocessor macros for critical calls. This is a bad habit because type safety is thrown away. GTK+ uses macros, too, but it uses them almost exclusively for safe type casting and enhances type safety in this way, instead of losing it.

For a short summary and comparison of the toolkits, I'll start with FLTK because of its unique position: It is the only toolkit discussed here which offers amazingly small and fast applications while still keeping a lot of useful widgets at the programmer's disposal. It is ideal for projects that need to be small and/or fast and programmers who like clean and straightforward interfaces. If you want to have a solid base and good internationalization or just want to program in plain C (ugh!), GTK+ is the all-around choice. gtkmm offers even more, and it has the cleanest and most structured API I've ever seen, but if you want extra functionality (OpenGL, for example), you'll have to rely on external libraries. If you're not an API purist, you can choose among the three huge toolkits, FOX, Qt, and wxWindows. I personally think Qt is made irrelevant by both of the others because they are not missing anything Qt offers. The tools that come with Qt may not be bundled with them, but comparable tools do exist and can be used free of charge, and most often as Free Software. Qt's biggest weaknesses are its relic called "MOC" and its business orientation. Yes, it's GPL, but not for MS Windows, so you're not really free. FOX and (especially) wxWindows offer similarly advanced sets of widgets and techniques, so you might as well throw Qt away. In terms of portability, it's the same, and wxWindows even adds OS/2 portability. Believe me, I don't want to be unfair to Trolltech or upset dedicated Qt developers. I tried to be objective, and that's my objective conclusion. Maybe we can discuss this point in the comments for this article.

Author's bio:

Leslie Polzer is a CS student living in Germany and working as a developer on several Open Source GUI projects, including the GTK2 programmer's text editor Beaver.

T-Shirts and Fame!

We're eager to find people interested in writing articles on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an article gets a t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about.

[Comments are disabled]

Referenced categories Topic :: Software Development :: Widget Sets

Referenced projects Boa Constructor - A RAD GUI-building IDE for wxPython. DirectFB - A hardware-accelerated graphics library on top of the Linux framebuffer device. FLTK - A C++ user interface toolkit for X11, Win32, and Mac OS X. FOX - A C++-based library for graphical user interface development. gettext - The GNU internationalization library. GIMP - GNU Image Manipulation Program. Glade - GUI builder for GTK+ and GNOME GTK+ - A library for creating graphical user interfaces. GtkGLExt - An OpenGL extension to GTK+. gtkglextmm - A C++ wrapper for GtkGLExt. gtkmm - A C++ interface for the popular GUI library GTK+. Lesstif - LGPL'd re-implementation of Motif Qt - A cross-platform development framework/toolkit. Tcl/Tk - A portable scripting environment for Unix, Windows, and Macintosh. UICollection - A one-stop solution for Java client user interface development. wxPython - A Python extension module for wxWidgets. wxWidgets - A C++ cross-platform GUI library. XForms - A GUI toolkit based on Xlib.

 Comments

[»] Tabular Comparison
by Code Medic - Jun 23rd 2006 09:47:41

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.

[reply] [top]

[»] Many thanx!!!
by Tony - Feb 2nd 2006 19:53:42

Many thanx!!! Very useful article!!!

[reply] [top]

[»] Re: Many thanx!!!
by Mrs. Karen Debbie - May 11th 2006 06:47:04


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

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

[reply] [top]

---

[»] tcl/tk
by Bill Poser - Jul 3rd 2005 00:18:28

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.

[reply] [top]

[»] In regards to . . .
by sid007 - Dec 4th 2004 12:01:36

I would say flexibility is the biggest advantage and as a programmer sid, Xlib allows more freedom and flexibility.

--
FavWebLinks Affordable Web Hosting Free Web Templates

[reply] [top]

[»] GTK and Windows stability
by Pantheraleo - Sep 22nd 2004 16:15:42

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.

[reply] [top]

[»] TCL Graphics
by xtended - May 30th 2004 19:35:31

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.

--
xtended

[reply] [top]

[»] Re: TCL Graphics
by Joshua Weage - Aug 17th 2004 07:10:42

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.

[reply] [top]

---

[»] http://www.hemmerling.com/html/en/framwork.html
by Rolf@DE - Dec 17th 2003 10:10:03

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

[reply] [top]

[»] "Raymond's Jargon File"
by Alp - Dec 3rd 2003 01:26:52

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

[reply] [top]

[»] A different perspective.
by Tom - Aug 20th 2003 21:48:19

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

[reply] [top]

[»] Re: A different perspective.
by blackhesonja - Jan 6th 2004 10:21:02

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

[reply] [top]

---

[»] Re: A different perspective.
by Jim Crafton - May 14th 2004 13:49:42


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

[reply] [top]

---

[»] Set Top Box GUI Kit Selection
by guidow - Aug 18th 2003 18:22:42

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?

[reply] [top]

[»] FOX, Qt
by cypherpunks - Aug 13th 2003 08:38:05

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.

[reply] [top]

[»] Breaking out of the Box
by peepo - Aug 12th 2003 23:49:16

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?

--
http://www.gnote.org

[reply] [top]

[»] Re: Breaking out of the Box
by Jon Wilson - Jun 20th 2004 21:53:38


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

[reply] [top]

---

[»] Qt from a professional perspective.
by David J. Sankel - Aug 12th 2003 20:58:45

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.

[reply] [top]

[»] Re: Qt from a professional perspective.
by MetaCosm - Aug 12th 2003 21:27:32

David -- thank you for the post, kept me from having to make the exact same post :)

[reply] [top]

---

[»] Re: Qt from a professional perspective.
by Antwerpen - Aug 13th 2003 01:58:45

% 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

[reply] [top]

---

[»] What about Java?
by Jon A. Maxwell (JAM) - Aug 12th 2003 11:16:12

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.

[reply] [top]

[»] Re: What about Java?
by c0nst - Aug 12th 2003 12:00:23

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.

[reply] [top]

---

[»] Re: What about Java?
by netmonger - Aug 12th 2003 12:39:23


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


[reply] [top]

---

[»] Re: What about Java?
by Jon A. Maxwell (JAM) - Aug 12th 2003 13:33:31


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



[reply] [top]

---

[»] Re: What about Java?
by Lloyd Budd - Aug 12th 2003 13:52:30

% 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

--
-- let me reflect on this.

[reply] [top]

---

[»] Re: What about Java?
by Frango - Jan 12th 2004 19:51:26


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


[reply] [top]

---

[»] Re: What about Java?
by David Walker - Jun 21st 2004 02:16:01


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

--
David Walker

[reply] [top]

---

[»] Re: What about Java?
by Antwerpen - Aug 13th 2003 01:47:13

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.

[reply] [top]

---

[»] Re: What about Java?
by Jon A. Maxwell (JAM) - Aug 13th 2003 07:31:36


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




[reply] [top]

---

[»] Re: What about Java?
by josiahcarlson - Aug 13th 2003 02:36:48

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.

[reply] [top]

---

[»] Re: What about Java?
by Dave - Sep 1st 2003 09:59:04

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

--
Dave

[reply] [top]

---

[»] Re: What about Java?
by Jon A. Maxwell (JAM) - Sep 1st 2003 16:33:19


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

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.




[reply] [top]

---

[»] Re: What about Java?
by Dave - Sep 1st 2003 20:01:11


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

--
Dave

[reply] [top]

---

[»] Re: What about Java?
by Jon A. Maxwell (JAM) - Sep 1st 2003 21:47:49


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




[reply] [top]

---

[»] Re: What about Java?
by Dave - Sep 2nd 2003 13:10:35

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


>

--
Dave

[reply] [top]

---

[»] Re: What about Java?
by Jon A. Maxwell (JAM) - Sep 2nd 2003 23:33:42


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



[reply] [top]

---

[»] Re: What about Java?
by Wallace86 - Jun 21st 2004 02:03:55


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

--
Carl Wallace

[reply] [top]

---