Cross-Platform GUI Toolkits (Again)?

Futurepower(R) queries: "It has been 2 1/2 years since the previous Ask Slashdot about GUI Toolkits. There were many helpful comments then, such as this one. Since then, Slashdot has discussed wxWindows vs. MFC and considered the book, Creating Applications with Mozilla. The best comparison table is apparently still the GUI Toolkit, Framework Page. Which is the best cross-platform GUI toolkit that provides native look and feel? Which is the best overall? What IDEs and other tools do you use? What are the problems?" Slashdot also had a match-up between GTK+ and Qt, but some of you might have missed that one. How have recent changes in this ballpark changed your feelings on the issue?

Comments

wxWindows

[MikeFM]

I like wxWindows and especially it's a child project wxPython. wxPython is my favorite way to develop GUI apps because it is easy, flexible, cross-platform, and looks great. My only major wish for it is a Java port so Python/wxPython programs could be made portable to Jython. :)

QT convert

[RiBread]

I developed apps with Delphi for 4 years and was completely sold that Borland had the best solution around.

At my new employment I had a project that needed to be cross platform. I was itching to use Kylix, however it wasn't due to be finished for another 8 months. Looking into the details I saw that they built the corss platform support on QT.

After checking out the QT tutorials I was immediatly hooked. QT is intuitive; I can't think of many other APIs I would grace with this description. In addition to being well thought out it has a superb implementation. I've been using it happily for 2 years.

The only thing I miss is the strong third party component community that Delphi/Kylix has. I'm a huge fan of "buy don't build". You can really put quality touches on your app by finding the right component someone else has already made.

-R

The best cross platform GUI toolkit I've used is..

[Admiral Akbar]

available with Eiffel Software's EiffelStudio development suite. It's called Vision2 and provides platform independent look and feel by using a bridge pattern to separate an interface layer from the underlying implementation layer (which uses the Win32 API and Gtk+ for the platform dependent stuff).

You can download the full EiffelStudio suite for linux (and Windows) and use it free for non-commercial software, Vision2 is included and is available here, it's free!

A few glitches in the Linux version...

[aquarian]

Eclipse does have a few glitches in the Linux version.

For those that don't know, Eclipse is based on a unique IBM GUI toolkit called SWT. It has a Java API, but the underlying code is native. The supposed advantage of this is that it can be used by any Java programmer as an alternative to Swing, but it's faster. The problem is that it's only available for Windows and Linux, and since the underlying code is native, it has to be separately developed and maintained. Since more GUI apps are run on Windows, there's more pressure to make the Windows code work right, and the Linux code is always a little behind.

I don't think there's any advantage to SWT these days, with Swing programming coming along so well. For anyone who doubts this, have a look at IntelliJ Idea, a really nice Java IDE that's Swing-based, and super fast. Frankly, I think Eclipse and SWT was a move to establish an IBM-centric Java community, with lots of vendor lock-in. Hijacking Java from Sun, if you will.

Eclipse *is* a really nice application, but I don't think IBM's motives in creating it were at all community-minded. And I don't have high regard, or high hopes, for SWT.

nonsense

[RelliK]

Tcl is a complete hack of a language. Imagine a Bourne shell, but with a totally ugly syntax. It is completely unsuitable for any sort of large application (and I have had an exteme misfortune of writing a farily large project in Tcl/Tk). What's wrong with Tcl? Let's see...

• It's a scripting language, interpreted on the fly. That means only the parts of the code that are actually being executed are parsed. You may have a syntax error in another part of the code, but you will not notice it unless you run that code. Even Perl parses the entire file before running it, but Tcl, just like shell, essentially treats the file as a stream of commands.
• It's weakly typed. This is actually the bane of all scripting languages that makes them unsuitable for large projects. You can assign an integer / float / string / file handle / whatever to the same variable without the interpreter even twitching.
• Here is a biggie: it does not force explicit declaration of variables.A variable simply comes to life when it's first used. Good luck trying to debug misspelled variable names.

And these are just my biggest objectsions. The Tk widget set is not bad. It is quite ugly and limited, but good enough for a small GUI app. The underlying language though is absolute crap.

The only good thing about Tcl is that it provides a (relatively) easy way of interfacing with C code: you can expose C functions as Tcl commands (e.g. you could map Tcl command foobar to C function MyFooBar()). This is, in fact, what Tool Control Language was designed for: exposing C functions to a high-level script to facilitate easy automated testing. However, trying to write a real application in Tcl is an excercise in futility. There are much better alternatives available. But, if all you have is a hammer, everyting looks like a nail -- that is why Tcl is the "past and future king".