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

Visual Basic!

[Anonvmous Coward]

Ha! Just kidding. Put the torches out, please.

Re:Visual Basic!

[goatasaur]

Funny, because I refer to something I use a lot as God's Tool.

Maybe not so funny.

Re:Visual Basic!

[phyxeld]

It looks like Qt does native widgets everywhere. I haven't coded with it, but source compatibility bewteen Windows, OS X, X11, and Qt/Embedded seems pretty promising. But personally, I'm still using the tried and true cross platform GUI toolkit known as HTML :)

Re:Visual Basic!

[infiniti99]

After using Qt for a couple of years, for both open source and commercial software, I can say it does the job admirably. It is easy to pick up, and using it is fun :)

Qt is not necessarily only for GUI. There are lots of convenience classes available to make your life easier doing cross-platform work: Text/Unicode handling, image, containers, networking, database, XML, etc. Many of these classes are highly optimized. I use Qt even when I'm writing a console app.

Though I have not used Java, I am told the API is very similar in style (to Swing?). The upside to Qt is that it is compiled and uses C++, so it is fast and you can mix and match system code. A common myth about cross-platform software is that you must cater to the lowest common denominator, which is absolutely not true with Qt.

Even if you are doing development for a single platform, you may still want to use Qt. It is generally easier to use than whatever is native (though I have heard very good things about Cocoa/ObjC), and it secures you that 'out' in case you want to port later.

For some examples of cross-platform projects using Qt, see Opera and Psi.

Re:Visual Basic!

[hobuddy]

Though I have not used Java, I am told the API is very similar in style (to Swing?). The upside to Qt is that it is compiled and uses C++, so it is fast and you can mix and match system code. A common myth about cross-platform software is that you must cater to the lowest common denominator, which is absolutely not true with Qt.

Even if you are doing development for a single platform, you may still want to use Qt. It is generally easier to use than whatever is native... and it secures you that 'out' in case you want to port later.

It's worth noting that all of the "upsides" you mention here also apply to SWT (for Java), PyQT (for Python), and wxPython (for Python).

It's not necessary to switch from a higher level language to C++ just to use a fast, cross-platform GUI toolkit that renders via native widgets.

FLTK

[Deflatamouse!]

The Fast Lightning Tool Kit is very nice. I've used it on Sun OS, Linux and Windows. Compiles between platforms without much change to the source at all...mostly its the system calls that needs to be changed, nothing related to the GUI.

Re:FLTK

[Deflatamouse!]

http://www.fltk.org

Re:FLTK

[SiMac]

The Mac OS X version of FLTK works, but it's mostly a joke. The widgets look nothing like Aqua; the menubar is (IIRC) at the top of the window rather than at the top of the screen. As much as I'd like to use it, it just doesn't adapt too well to OS X.

Re:FLTK

[printman]

The plastic scheme gets you closer, and assuming that Apple doesn't jump all over us the 2.0 release will have an Aqua scheme as well.

As for the menubar at the top of the screen, you just have to use the Fl_Sys_Menu_Bar widget.

Re:FLTK

[oingoboingo]

FLTK looks pretty awful though. We have a bunch of custom apps here at work coded in C++/FLTK and they don't look like they fit in anywhere...they look as alien on my KDE desktop as they do on a Windows 2000 box. They've got some weirdo widgets in there too...there's that one with the little rolling wheel that you use to increase or decrease a value...what's the deal with that?

Actually, none of these things may actually be FLTK's fault...the guys who developed the apps haven't got an aesthetic bone in their bodies so maybe the shitty look of the apps is more due to them than the toolkit.

Swing.

[XNuke]

Seriously, the question wasn't limited to C/C++, which brings lots of other baggage besides teh GUI.

kinda ironic

[cr@ckwhore]

Kinda ironic that I'm seeing a .NET ad on this page

Cocoa or GNUstep

[kwoo]

I personally think that Cocoa and GNUstep deserve to be mentioned among the best-designed toolkits around. Both follow the OpenStep guidelines rather closely, and the OpenStep guidelines are very well-documented on Apple's site.

GNUstep is also quite portable -- I have used it on three or four platforms, and have no doubt that others work great. My only complaint about GNUstep is its idiosyncratic build system, but I believe that's a left-over from NeXTSTEP, the precursor to OpenStep.

If you're interested in learning more about Cocoa and other OpenStep-compliant toolkits, check Apple's developer site and the Hillegass book, published by AW.

Re:Cocoa or GNUstep

[root 66]

First, some resource for GNUstep (for the lazy ones):

http://www.gnustep.org - Main GNUstep site
http://wiki.gnustep.org - GNUstep Wiki, lots of tips and hints
http://www.gnustep.net - collection of docs, Build Guide
http://www.gnustep.it - Tutorials, applications, etc
http://www.gnustep.de - some German translations but also English information

Second, GNUstep makes pretty good progress these days. Gorm, the Interface Builder clone, is rather stable and _very_ nice to use. Also there is now Renaissance, another way to build an interface. (Renaissance is also usable on OS X!)
Within the next months there will be a new and well done text system.

The base system has been stable for about a year now, and the gui classes are mostly usable - a lot of gnustep applications were released some time ago.

Swing

[Tom Davies]

Swing is functional and cross-platform, free-beer, and widely understood.

Re:Swing

[Minna Kirai]

Swing works on a single platform: Java. And not all Java, either.

Re:Swing

[viktor]

Swing might be cross platform, but it isn't native look-and-feel, which the original poster suggested the topic of discussion was.

Re:Swing

[viktor]

Yes, the easy part is getting the look right, natively or otherwise.

But the feel is an entirely different can of worms. Then all the stuff like whether OK buttons are to the right or left, where the menu-bar is at, whether it's Ctrl+Q or Alt+Q or Cmd+Q to quit an application (and whether Quit means "close the active window" or "close all windows"), what dialog titles should be (or if they should be sheets as in Mac OS X) and everything else comes in to play.

And without it, native look-and-feel isn't. ;)

To be honest, I've yet to see anything that gets even close. Mac, Windows, KDE and Gnome have so different paradigms that it would be an incredible acheivment to create the first true native-look-and-feel-cross-platform toolkit.

SWT using Eclipse

[DamienMcKenna]

The SWT engine in Eclipse seems pretty cool - rather than using Java's standard slow SWING engine you get a toolkit that passes through to the native UI, which results in a much more responsive application.

Re:SWT using Eclipse

[mamba-mamba]

Actually, you would think that a native widget app would be faster, but lots of people claim that SWT + gcj (or javac) is NOT faster.

I've never done a benchmark myself.

I do suggest that people who want to try SWT plus GCG go to my sourceforge project, libswt.

--
MM

Re:SWT using Eclipse

[bmetz]

As someone who writes SWT and eclipse apps for a living, I can say quite definitively that if you're aligning your widgets based on assumptions about pixels and whatnot you are in fact a moron. Microsoft won't let you use their logos with any app that does this either; they know that when Microsoft Windows 2008 comes out they might drastically change what your Win32/MFC calls produce on the screen and they want you assuming as little as possible. No professional programmer hacks it until it works, and if they do, it's certainly no more SWT's fault that it is GTK's fault when someone in a right-to-left language finds out how you didn't stick to the recommended methods.

Layout in SWT can be done any number of elegant cross-platform ways and only as an absolute last resort should you ever have to use absolute pixel amounts. And don't think this is just a cross-platform issue -- people who jack their font sizes for certain widgets up (namely, me) but not others find improperly laid out controls very very quickly. I can vouch that Eclipse in fact does not have much of this if at all. Typically, if you're coding this way, you need to go back to Layout Managers 101.

Re:SWT using Eclipse

[@madeus]

No professional programmer hacks it until it works

I think that is evidently not true.

Sadly, layout managers cannot do everything a developer can envisage with out such pixel based kludging. In particular, cross platform layout managers are almost guaranteed to give you an aesthetically (and often functionally) ugly result on at least one platform.

While it is important to make applications behave 'correctly' under varying conditions, such as UI theme's (a topic around which there is a big debate), resolution and font size, it is not acceptable that developers should design programs within the confines of an inadequate layout manager, particularly when the know the layout manager is not up to the task.

I'd also add that it is utterly unreasonably for developers to be forced to build UI's that are governed by the possibility of major changes in the way user interfaces are rendered on screen by the operating system - changes that may or may not happen, and if they do, will not happen for another 5 years.

If an operating systems developer such Microsoft decide that they wish to drastically change how a user 'views' an app, applications should re-released with that new approach in mind. Existing UI's should not be 'shoe horned' into working with a drastically new approach, and they should certainly not be limited by the requirement that they may be subject to unforeseeable changes in the way the widget-rendering API's behave.

I think to argue otherwise is to undervalue the importance of a good User Interface.

Case in point:

Microsoft applications for Windows CE required that you not provide any way to quit the application - if you did you were not allowed to use the Microsoft logo in conjunction with your product. This of course was a fiasco and made WinCE devices usable (without a 3rd party hack to work around the problem).

TK...

[velcrokitty]

Nice and portable and reasonably consistent feel and appearance.

And for those who like to use it in a scripting environment, use it as is. Use it with Perl, C, C++, etc...

Re:TK...

[Xtifr]

I have to strongly agree, it's simple, it's reasonably clean, it's popular, it's been around long enough to well supported and accepted. And it runs on just about anything out there. And it's the default widget set for most of the most popular scripting languages: perl, python, ruby, and of course, tcl. Yet somehow it stays apolitical.

Of course, I may be accused of bias, since I'm the new Tcl/Tk maintainer for the Debian project. But in all honesty, I don't even care that much for tcl. It's ok, but nothing to write home about. It's tk I like, and tk that made me willing to adopt these packages.

Re:TK...

[DavidNWelton]

Tcl/Tk is great. Lots of people certainly get great mileage out of it doing "quick and dirty", but if you design your code right, it can be quite clean as well. Tcl is flexible enough, and has enough of its C API exposed that you can load OO as an extension - [incr Tcl] is a popular one, if you want to do OO. Of course, it's possible to do "design patterns" kinds of things even without that, you just have to be clever about it.

Re:TK...

[RussP]

Check out GVI, the Graphical Voter Interface, which I wrote in Tcl/Tk. I think it's pretty cool.

Eclipse

[asv108]

If your looking to Java for cross-platform development and cli is not your thing, Eclipse is a nice IDE that works nicely on windows and linux. Its also open source.

Tcl/Tk is the past and future king

[nuzoo]

If you're talking about true cross-platform compatibility, combined with ease of development and deployment, then Tcl can't be beat. It's always been good, but recent developments, such as the Starkitpackaging and runtime system, make it a hands-down winner.

Re:Tcl/Tk is the past and future king

[nuzoo]

"available on Unix" ? Au contraire. In fact, the overwhelming majority of Tcl developers distribute their apps for Windows these days, though those apps will typically run on just about any platform without changing a line of Tcl code.

A sampling of companies heavily reliant on Tcl can be seen at http://www.tcl.tk/customers/success/

The Tcler's Wiki is probably the hub of the most activity: http://mini.net/tcl/0

A brief list of cross-platform Starkits available is at http://mini.net/sdarchive/ though the Starkit system makes it trivially easy to package and distribute complete applications for multiple platforms. For an impressive display of what can be with a Tcl Starkit, you can check out Kitten, which is "a tclkit collection of [over 100] Tcl/Tk extensions aimed at reducing the work a developer has to do while developing a starkit. It contains script and compiled extensions like tcllib, BWidgets, expat, Expect, incr Widgets, mclistbox, mpexpr, narray, a tcl parser, an sgml parser, tclSOAP, stooop, Supertext, tdom, Tix, Tktable, tclXML, tkHtml, ClassyTk and others."

Re:Tcl/Tk is the past and future king

[Lucas Membrane]

I agree ... except that it doesn't respect screen settings very well on Windows. About 15% of apps written in Tcl don't work ok on my machine, either the window doesn't fit on the screen (because it's 800 x 600) and the programmer forgot to add a scroll bar, or the text doesn't fit in the window (because it's large fonts), or I can't read the text, because it doesn't come out in large fonts. HTML has similar problems, particularly lots of stuff that doesn't fit into the designated frames and often the scroll bars are not present on the frames.

There are about 130 relatively plausible configurations of screen size and fonts under Windows. There are very few toolkits that will work well with all of those, and that's on just one platform. I know of someone who tested Delphi and VB against all the combinations and found that they each worked well with only about 90%. Cross-platform that will handle all the variations on multiple machines and look good and make it possiblt to put a reasonable pantload of data on the screen regardless -- likely impossible.

Java

[gUmbi]

This might be a little too obvious, but how about Java - a cross-platform language, API and GUI framework.

And, if the speed of Swing bothers you, you can try IBM's SWT toolkit. I'm very impressed with it so far.

Jason.

Re:Java

[plierhead]

The question is, at best, a little too simplistic: Which is the best cross-platform GUI toolkit that provides native look and feel? Which is the best overall?

I myself would favour Swing over others, though I'm really only fully conversant with MFC. But I fully realise that it depends what you're doing.

If you're building a mass-market app you plan to sell you all of the great unwashed out there, then you probably need to make it look very Windows-centric. Practically speaking, something like a turbo tax is probably going to get 99% of its revenue from Windows users. Its crazy to use anything - like Swing - that doesn't give you the best, most up-to-date look on Windows (though Sun would claim it is native look and feel). Use MFC or something like that.

If on the other hand you're building something like an IDE, other factors come into play. The fact that your app runs on linux as well as Windows will probably be a key sales point to your target audience. And your app is probably far more complex than a mass market app - meaning you need good productivity and a strong underlying architecture(which, IMHO, Swing gives you). Your users are likely to care less about the memory requirements of a technology like Swing.

Or as a final example, if you're writing a game, then screw their sheety GUI ! Code everything yourself from lines, dots, and mouse events. Make your list boxes scrollable using human skulls as thumbtabs, have rats running up and down inside your text fields to show focus. (personally I would also use Swing for this but realise that may be straying into personal predjudice).

In summary, its no good saying "whats best". It depends on what you're coding.

Re:Java

[afidel]

Yeah and winamp pisses me off for not using the native widgets all the time. When I upgraded to XP minimized winamp windows would leave a little block under the start bar, this was fine as long as you didn't have autohide on, if you did it was kind of rediculous looking and it would not re-maximize from this state. Another problem is that a vbscript I have bound to one of the keys on my internet keyboard allows me to minimize and maximize any windows, except it doesn't work with winamp because the standard calls don't work! There are sucessfull non-native products out there including for many years winzip, however in general I would say that sticking to the native tools is a definite plus.

X-Platform GUI Toolkits

[GQuon]

I'm sure Microsoft will provide GUI toolkits for the X-Box themselves. They don't need a bunch of geeks working on some kind of open source solution. Everybody knows that open source is just a fad. Microsoft said so.
;-)

I would keep an eye for mono

[kbroom]

It is hard to admit it, but when the mono team gets windows forms working correctly, C# and .NET are going to pick up a great deal of momentum, specially in the cross-platform GUI development area.

SWT

[jaaron]

Okay, I'll bring it up now: IBM's SWT is great. I've been using Eclipse lately under gnome2 and it's wonderful. Nice native look and feel (great anti-aliased fonts) and very responsive.

If you don't know, Standard Widget Toolkit (SWT) is a java GUI framework that uses JNI to call the native OS windowing API. It's an excellent example of how java can successfully be used for client desktop applications. IBM developed it for the open source Eclipse IDE.

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

Re:wxWindows

[pnatural]

I've been coding for wxPython for months now. It's a great gui library, it's fast, it's portable, and it has tons of controls. It's flexible, and it's free. The docs are good, too. I cannot imagine switching to pygtk or pyqt at this point.

My only bitch is this: the development model all but forces the programmer to reuse thru inheritance, not composition. I realize that inheritance was the preferred method of OO reuse when wx was originally conceived and written, but reusing wx types thru inheritance is painful because it leads to lots of (very similar) code.

Qt still wins

[motorsabbath]

I like wxWindows but it's not nearly as well and copiously documented as Qt. Also, being able to build code in Linux, FreeBSD, OSX and Windows (at work) is very, very, very cool.

Qt all the way!

Re:Qt still wins

[dcuny]

I'm not sure why you wrote "also", since Linux, FreeBSD, OSX and Windows are all supported by wxWindows. Plus, wxWindows supports just about every compiler under the sun.

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!

Kylix / Delphi

[Mr_Tulip]

I've used a mixture of Delphi, Kylix, HTML and PERL on a few projects. It's cross-platform, as long as you only need Linux / Windows, and the basic version of Kylix is Open Source as well as free as in beer. You can also choose to code in C++ or Object Pascal.

Here's the link with more info: Borland Kylix Open Edition

-My Karma ran over your Dogma

WxWindows?

[Futurepower(R)]

What has been your experience with WxWindows? The web site says that WxWindows provides a native look and feel on Windows, Unix, or Mac. There are IDEs and other tools.

Re:WxWindows?

[Hanji]

I'm a big fan of wxWindows - really nice look AND API, but I've had trouble getting any of the dialog editors to work (I'm under OS X), which has been something of an annoyance, since, as any GUI programmer can probably tell you, implementing GUIs entirely in code is a huge pain in the ass, and is harder to change later on than if you use a resource file...

Re:WxWindows?

[Fnkmaster]

I've used wxPython to build a fairly large GUI application. It was actually an annoyingly complicated project, for reasons that were not really the fault of wxWindows, and Python probably wasn't the right language to use (sometimes strong typing and compile-time type checking are really nice to have around).

Anyway, you see a lot of Qt fans around here. Qt is nice, and is unbeatable for its documentation quality and the cleanness of extending the base widgets with new composite widgets, and extending the base objects with new behaviors. wxWindows can be a bit more awkward in these ways, isn't always quite so clean and well architected as Qt, and definitely isn't as well documented (especially if you are using the wxPython bindings - reading C++ docs with "annotations" is annoying).

However, wxWindows uses true native widgets, not rendered widgets that look and feel nearly native (Qt - it does a pretty damned good job of it, not like Swing or something, but it's still not using true native widgets on Windows). wxWindows is also free (as in beer) for use in commercial AND Free Software applications, licensed as LGPL with the exception that derived works in binary form may be distributed on any terms you want. In other words, no restrictions on commercial use or licensing. Qt is GPLed or commercial software. Meaning you can either use a GPL-compatible Free Software license, or you can license their commercial version, which is fairly expensive (for a hobbyist or private individual - and not exactly cheap for a company if you have to buy a bunch of seat licenses for your developers).

If you can afford it, and don't mind the fake painted widgets, then Qt is the way to go. If you want real native widgets on Windows, OS X, and X Windows, and you are on a budget, then wxWindows rules - just expect to sometimes have to bang your head against some annoying documentation or some unfinished features (wxGrid anybody? God fucking damn if I didn't build an entire app around a wxGrid only to find out it doesn't exactly work as advertised all the time... grr...).

Most importantly, ignore the posts about how the "feel" isn't quite right on some platforms. If you really want a slightly different menu layout or some such thing for each of the several platforms, it's pretty damned easy to add a few lines of conditional compilation (for a C++ program at least) to switch a few things around - and since the joy of Unix is that X apps have no fucking standards anyway, that app you wrote that looks good on Windows will probably look just as good in X - just make sure you test the OS X version out if that's a target platform, since I imagine you need some extra work to make things truly meet the Macintosh platform guidelines. Still a ton easier to maintain one wxWindows source base than to maintain a Gtk, MFC and Carbon/Cocoa GUI separately.

Re:WxWindows?

[kollivier]

Most importantly, ignore the posts about how the "feel" isn't quite right on some platforms. If you really want a slightly different menu layout or some such thing for each of the several platforms, it's pretty damned easy to add a few lines of conditional compilation (for a C++ program at least) to switch a few things around - and since the joy of Unix is that X apps have no fucking standards anyway, that app you wrote that looks good on Windows will probably look just as good in X - just make sure you test the OS X version out if that's a target platform, since I imagine you need some extra work to make things truly meet the Macintosh platform guidelines. Still a ton easier to maintain one wxWindows source base than to maintain a Gtk, MFC and Carbon/Cocoa GUI separately.

Just a quick note: I've used wxPython to develop an application and I can say that it does very well in the "look and feel" department. It sometimes even goes "above and beyond" the call of duty - wxMacPython, for example, will rename your "Exit" menu item to "Quit" automatically. There are also notes on how to make a wxApp more "Mac-friendly". As a developer working on Mac but developing primarily for Windows users, I can say wxWindows/wxPython really works well for me. And while the documentation isn't the greatest, it is pretty decent considering the constraints of an open source project, and the folks on the mailing lists are more than helpful when you have a question, or even find a bug. =) Just my $0.02!

Depends on the task

[darkwiz]

For the kind of GUI-I-Wanna-Slap-Atop-A-Database, I like to use Tcl/Tk. Works great for programs where you just want to have something quick, rapidly prototyped AND cross platform.

If you really want a well orchestrated OO GUI toolkit (with the exception of some nasty hacks), QT is a great thing to couple with C++. I know there are many out there that cry foul at the MOC. For the uninitiated, QT uses a macro processor to add a few keywords to C++ for their Observer(or Publish/Subscribe) pattern. I feel that these extensions are minor, and do not significantly detriment the portability of the code. That is, unless you are insane and derive EVERYTHING from QObject - then you are going to be heavily dependent on QT. In a well abstracted interface, your main code tree shouldn't contain much, if any, GUI code.

I have a lot of respect for GTK+, but it just isn't for *me*. GTK programs do generally feel a little more responsive on slower hardware, and are generally lighter weight (being mostly pure C), but the question seems to revolve more around cross platform programs, and GTK doesn't seem to integrate very naturally with the other platforms - at least not the programs that I have seen.

Re:Depends on the task

[Greyfox]

The C++ wrappers for GTK have come a long way. They make deriving new components a breeze -- just slap together something derived from the closest widget to what you need, add some hooks so you can put stuff into it and get stuff out and drop it into your favorite layout tool. The signal system is pretty slick too, and doesn't use a preprocessor. The signal system alone is worth looking at -- I could see using it in non-GUI projects.

FOX

[barole]

We are using the FOX toolkit and we are happy. It is a simple toolkit, designed and implemented mostly by one person. It uses the primitive drawing routines of the underlying platform (win32 or X) so looks the same on all platforms. It is written in C++, but there are ruby and python bindings.

The author has spent a lot of time looking at existing UI libraries and tried to learn from them before writing his own.

See the website for more info.

Re:FOX

[JoshRendlesham]

It should also be noted that there is an addendum to the LGPL licence covering FOX that clarifies several issues. Unmodified versions of the FOX library can be statically linked to applications without causing licensing headaches, however, any changes to the library must be made available.

This may be attractive to developers who wish to simplify the distribution of their software by statically linking in FOX, but without putting their work under the LGPL as well.

Re:HTML

[jaaron]

Isn't that what Javascript is meant to be for?

Well mostly. I think Javascript is wonderful when used correctly. However, the other poster still has a point:

HTML as a GUI really lack when you need need to cause change. There is no easy way to "push", so different UI elements can't really be informed when the data they are displaying is changed.

I recently had a project that we wanted to deliver over the web. We have a lot of data that we needed to display in real time graphically and have it dynamically updated while the user is viewing it. This is simple in a classic networked application by using a "push" method of delivering the data. However, for HTML and HTTP, AFAIK there isn't a good solution. Once the page is rendered, that's it. Either you continuously refresh the page or you have some sort of applet or other plug in running. Applets wouldn't suite our situation, so we eventually went for Java WebStart, but I really wish there had been some sort of solution that could have worked directly in the browser.

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.

Re:A few glitches in the Linux version...

[yiingineer]

Actually SWT has several really nice advantages. I agree that Swing has improved a lot in the past few years, but Swing apps are still not native apps and users can certainly tell the difference. SWT applications are essentially native applications not only in appearance, but also in functionality. There will always be little keyboard shortcuts or imcompatibilities that Swing will miss that SWT programs inherently account for because they use the native implementations underneath. SWT apps are generally considered more responsive than Swing apps. As cross-platforms toolkits go, the one-to-one mapping design philosophy has also been embraced as a great idea from an architectural stand point. (see http://www.eclipse.org/articles/Article-SWT-Design -1/SWT-Design-1.html for reasons why) The SWT is not available for only Windows and Linux. It also works on Motif (for Unixes), Carbon (Mac) and I think they even have one for and embedded platform named QNX. Also, IBM had no intentions of creating an "IBM-centric Java community" with the development of SWT. SWT was originally created to be used in Eclipse and the simple reason why they didn't use Swing was because Swing was horribly slow and ugly back then. I would say that it still is fairly slow and ugly, but one might argue that if Swing was in its current state when the Eclipse project was started that IBM may not have bothered to create the SWT.

Java / Swing

[Whatsmynickname]

I know I'll get beaten up for this, but how about Java / Swing? One project I wrote had to work on W2K, Solaris, HPUX, and SCO. Plus, I had to use a C library to boot. Had to develop a client with tabbed pages, trees and grid controls with drop down lists within cells. What did I use? Java with the Swing GUI library. Although it had some limitations, I was able to successfully port the app across all machines with virtually no code change! I liked the Swing architecture much more than other libraries I've used.

Jabbascript.

[Anonymous Coward]

You can update the inner xml of a tag by using Javascript to make an http request for a string.

For example, the way that Kuro5hin has dynamic threads. They keep a stub of each comment id, and then run javascript to dynamically load the comment's contents when requested.

I'm not sure whether it would have worked for you... real time graphical information -- so you needed to reload an image? How often?

It's not suitable when you want to change an image ten times a second, but if your application would suit 2 or 3 second updates then there's a lot you can do with Jabbascript.

Ahh Jabbascript.. the world doesn't know what you can do.

Qt?

[Futurepower(R)]

Trolltech's QT costs $1550 each, per developer, for commercial use on Windows and Mac.

QT versus Java (PDF file)

QT versus MFC, in English (See the French below.)

QT versus MFC, in French (MFC contre Qt)

Re:Qt?

[cje]

The key word there is "commercial."

Qt is free if you're developing free software.

Incidentally, as somebody who has used both the Free and Commercial versions of Qt, I can vouch for the quality of Trolltech's support. Any technical questions that we've had about the library have been promptly answered, bug fixes have been handled well, and they are always receptive to requests for new features.

Re:Qt?

[vrt3]

Qt is free if you're developing free software.

Yes, but the Non Commercial Edition for Windows is still at 2.3 while other versions are at 3.0, and Trolltech doesn't seem to have animo to upgrade the Non Commercial Edition.

pyGTK is the EASIEST GUI toolkit

[daveaitel]

pyGTK with Glade is the EASIEST GUI toolkit. It may not be the "best" but I've built a commercial, cross platform application using it (here is a screenshot) and I am a complete retard at GUIs. It took a total of 2 weeks - from complete scratch. Porting it to Windows for my customers is just a matter of installing a few simple .exe's - they are used to that anyways. Because the GUI is actually a .glade XML file, I don't have to write any code at all every time I change it. It just makes more sense than having to worry about integrating your entire IDE into a GUI builder!

Realistically this should not be an issue IMHO.

[FooMasterZero]

For the majority of the time I create GUI's in Java's Swing API. Despite what the purists say, my experience has shown that with a little bit of fore thought and not having Swing developers rely on GUI builder tools that create some pretty bad code, a.k.a JBuilder which is a good example of this. I personally like the SWT approach via IBM Eclipse project, yet purist will most likely say that this toolkit suffere or will suffer the same quasi-proprietary baggage that people claim Swing suffers from with Sun's involvement with Java.

However with the subject at hand, why are GUI toolkits such an issue anyways. This seems like a senseless battle that tends to reflect a typical male chauvinism of mine is bigger and better then yours so NAH !.

I have no experience with most of the *nix toolkits as they honestly gave me no reason to start since I could never figure out which one was the most sensible to use. This is something I am sure alot of *nix developers face as they decide things like "Do we want GNOME support, KDE support, both ?" Working with MFC some they are all right of course there is not the smorgasboard of choices present in the windows world as *nix worlds. I think in Win32 for native Toolkits you are limited to MFC and QT, I could be wrong.

So now the question is not really what toolkit is the best to use, but which toolkits can simply go away. Realistically how many different usable ways can you create a window and manipulate a window component. I ask this becuase i have managed to create very nice platform independant GUI's that work damn near identical on linux, mac, and windows and with the exception of win32 and linux since the Java Look and feels don't emulate the environment 100%. However disregarding certain things they pretty much look native.

So if Java API's are good enough to create an abstraction layer to the native look and feel. Whats to say that idea can't be taken a step further and take the java factor out, this is similar to SWT approach. I mean seriously lets show some innovation here, instead of trying to declare on toolkit over another based on the premise that something as silly as showing a round button with gradients versus a flat rectangular one with no gradient colors.

On a final note of this rant, a simple standard toolkit for platforms to could encourage developers to work with simpler toolkits that give them the benifit of working on multiple platforms with confidence, this way more developers more applications that are available to more people then just select few for whatever platform the choose. For those purist or XXX toolkit zealots out always remember if you have special needs that a standard toolkit doesn't provide you can always go one step further and do it yourself, i mean there is always assembly right ?

Text/Note Pad

[Beatnick]

Everyone knows a good developer uses just a
simple text editor. ;) Just kidding of course.


For me, I see the many aforementioned GUI kits
as great tools but it all comes down to what
the job demands/dictates. I find myself being cross-trained
instead of cross-platform developing. Every contract we take on,
we are asked to perform it in the company's chosen dev environment.
Anyone else in this predicament?

Does anyone know of a site that tracks various
IDEs that are currently in use?

If your company requires multiple IDEs as mine does,
who supplies you with the training to effectively
use the tools as well as the languages themselves?

If Bill Gates decides to marry Britney Spears?

[Futurepower(R)]

Yes, but doesn't it make a difference that WxWindows is:

1. Open Source. You can fix it, or ask someone else to fix it if something goes wrong. If Bill Gates makes an anti-customer decision (Would Bill Gates do that?), you are protected. If Bill Gates decides to quit Microsoft and become a wind surfer, you are protected. A downturn in the fortunes of Microsoft does not become a downturn in the fortunes of your company.
2. Cross Platform. It is impossible to predict how popular other operating systems will be. You may want a Linux version of that Windows product.
3. If necessary you can always make a call to MFC. Using WxWindows does not stop you from using MFC for some special need.

Re:Different paradigms, different toolkits

[TummyX]

What a load of crap.


X is based on a networking concept where anyone can access anyone else's screen as a network resource. This leads to multi-threading issues as it is possible for two people to use the same desktop, even same application, simultaneously. As a result, toolkits that have their origins in that environment like GTK and wxwindows have strong multi-threading support not to mention strong networking support


Your conclusion doesn't follow from your premise. The X *protocol* isn't the reason why GTK and wxWindows have strong multithreading support.


This results in the base windowing subsystem's reliance on processes as the fundamental object of execution (as opposed to threads).


What a load of crap. Processes as the fundamental object of execution as opposed to threads? Do you even know what a thread is? Every process in Windows has at least one thread.

So toolkits built upon Windows (MFC, OWL, QT) are able to harness Windows's windowing support in a way that more easily and effectively takes advantage of the features of the subsystem.


Yeah, whatever. QT works the same on Windows as it does on Unix.


Attempting to port one toolkit from its home platform to a foreign platform leads to problems of "look and feel".


Well this doesn't even have anything to do with the networking issues you raised before. It's all about how you draw the UI widgets.


AWT and Swing are prime examples of toolkits that look strange whereever they are used.


Idiot. AWT uses native widgets. And Swing could be made to look practically identical to the native OS. It's all about how you draw the widgets and there's not much stopping Swing from getting it pixel perfect.


Likewise, wxwindows feels funny running on Windows and GTK looks funny. Hell, MFC doesn't even run on X.


What about wxWindows 'feels funny'? And MFC *does* run on X, there are Unix ports. Though, why you would ever want to use a monstrosity like MFC is beyond me.

ZooLib has a native look and feel

[MichaelCrawford]

I'm a big fan of Andy Green's ZooLib, at:

• http://zoolib.sourceforge.net/

It draws its own widgets, but uses switchable renderers so it maintains the platform look and feel. It uses the Appearance Manager if it is available on the Mac OS. It put the menu bar in the windows on Windows and across the top of the screen on the Mac.

It supports Mac OS (68k, PowerPC, classic and Carbon), Win32, BeOS x86 and Linux. It would not be hard to bring it to a totally new platform.

It is in C++, is multithreaded, and provides a complete solution - not just GUI but TCP networking, file I/O, streams and persistent storagge.

If you use it, I suggest you use the version in CVS as a lot of work has been done since the last release. A new release is planned soon.

I have started writing a tutorial called The ZooLib Cookbook.

ZooLib is under the MIT License and the Cookbook is under the GNU Free Documentation License.

ZooLib has actually been around longer than even wxWindows, but it was only placed into open source in the fall of 2000. Among the applications written with it is Knowledge Forum.

Omnis Studio

[ThadMan]

Omnis Studio (www.omnis.net) is a multi-platform application development environment that allow you to build business centric applications. It allows you to develop an application on one platform and deploy to all other platfroms with little or no code changes. The deployed applications have a native look and feel. Currently Studio supports Linux, Windows, Mac OS 9 and X, and Solaris.

From what I hear, there is even support for Windows CE (or whatever it's called) planned in the future.

Studio also has a client that allows to embed a fully gui application in a web browser too.

It's pretty amazing stuff; especially since the technology has been around sice the Apple II!

Re:vanity?

[cheezfreek]

Users will judge a product based on how it performs, and (hopefully) not how it looks.

Unfortunately, that's not how it works for most people. To most people, if a program doesn't "look right", then it doesn't "feel right", so it must not "work right". And when people reach this point, they've decided that the program is a "piece" of "crap", and to hell with the "functionality", they just "know" that it "blows large ass".

Re:The web?

[VividU]

Well, until Microsoft took it over, the Web was a very good multi-platform development environment....

Your post is a mediocre troll at best, but what is interesting is that it was moderated to (+5 insightful).

The Linuxites are out in-force tonight!

One person's analysis:

[Futurepower(R)]

One person's analysis and comparison of GUI toolkits: Why this GPL programmer didn't choose .NET

Re:The web?

[dimator]

Hmm... ya, you're right. I remember the days when word processors and 3D modeling applications were all written in HTML and javascript for all to use... fucking microsoft...

Excellent book..

[TheTomcat]

on PyQT:
http://www.opendocspublishing.com/pyqt/

Python: cross platform
QT: cross platform, native-working widgets.

QT, however, isn't free for commercial use.

S

Trying to Answer the Original Question, v. 2.0

[Futurepower(R)]

I reformatted the parent post. No other changes:

As usual, this thread has wandered pretty far from the original topic, which is a shame considering that this is a fairly important issue for a lot of people. I do actually have a little experience in this area, so here's what I know that might help:

wxWindows: If you're going to stick to a C++ cross-platform application framework, I honestly believe this is the best option. Most people don't seem to pay much attention to it, and many of those who have were burned by bugs in earlier versions, but it's really starting to come together in terms of both stability and functionality. I ported early code for a pretty complex program from MFC to wxWindows within 2 months, which impressed me considering that I wasn't familiar with either toolkit and that was my first real use of C++.

I'm now doing a bit of work with wxPython, which is also going pretty well.

The Mac port development tends to lag a bit behind the others, but it has been (and is being) used to deliver several commercial products, so it seems to be in usable condition; I haven't had a chance to test it myself yet. By all means, please carefully consider this option; it seems to be the most capable framework of it's type currently out there, has a respectable number of users and developers, and will get even better with more support.

CPLAT: Afraid I can't say anything as positive about this one; the MFC project I mentioned above was itself a port from CPLAT. After 2 months of development with CPLAT (ending January 2000), the developers unanimously agreed that the framework was so buggy that it would be faster to write separate versions of the program for MFC and PowerPlant. I believe there is only one developer on the project; that simply isn't enough resources to properly handle a framework of this magnitude. Whisper: We looked at this one also, but it didn't have enough of the features we were looking for to be worth trying. It also looked to be, like CPLAT, a one-man effort.

YAAF: Another one we passed over after a brief glance. The web site didn't have much information, and I don't see any indication that it's being used much. I may have short-changed it, but I just don't see enough activity around it to indicate a really good product.

GLUI: I haven't used this or looked too closely at it yet. The lack of native widgets bothers me, though...

Carbonless Copies: Hadn't heard of this before. The web site given above hasn't been updated in a while, I haven't heard of many people using it, and it's a proprietary program; I'd be inclined to avoid it.

Regarding some of the other options people have suggested:

Java: While useful for some purposes, cross-platform GUIs arguably isn't one of them. It's relatively easy to get a Java GUI program to work cross-platform, but practically impossible to get it to work well. AWT lacks major functionality. Swing is buggy and a *massive* memory hog; don't even think about running Swing apps on computers with 32 MB of RAM, and they're not terribly happy even with 64 MB. And Java in general is lagging far behind on the Mac. Finally, it is a proprietary platform complete with all of the problems that entails. I used to really like Java, but not much progress has been made at solving some of it's critical deficiencies. I'm now hoping Python can take it's place...

Mozilla: Mozilla is useful, but it's deficiencies have been noted above; lack of native widgets, slow response time to user input, etc. I look forward to using this for some projects, but it isn't going to replace the need for a cross-platform C++ application framework.

GTK+: Doesn't work on the Mac, and won't for some time to come. Doesn't use native widgets on Windows, either (to my admittedly limited knowledge.) I agree with the wxWindows approach; use GTK+ on Windows, use the Windows API on Windows, and use the MacOS API on the Mac.

Qt: Again, doesn't work on the Mac and doesn't use native widgets on Windows.

Tk: Doesn't have native look and feel, and last I checked has some issues on MacOS. I've also gotten the impression that the widget selection isn't as rich as that of wxWindows, although I haven't looked at it closely enough to judge for myself.

On the topic of RAD tools; wxWindows does not yet have a usable RAD tool, although the wxStudio IDE is under development and there is a working dialog and panel editor.

wxPython has the Boa Constructor IDE which seems to be almost in usable condition; it could also be argued that compared to using C++, even manually writing Python code practically *is* a RAD environment. Hope this successfully addresses some of the issues, and hope it isn't buried so far down in the responses that it never gets noticed...

Re:Well, what about .NET?

[spongman]

some nice screenshots:

• Gtk#
• Gtk# samples
• Qt#

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

Re:nonsense

[pyrrho]

which is interesting because this is the point of TCL... TCL has a very good attitude about itself in that it's not presented as the end all be all language, one language for all. TCL justifies script languages as a means to tie together all the components that are carefully created in optimal, compiled, languages.

This is appealing as a philosophy because it's the reality that most seem to wish away... many languages always crying for various types of integration. But it's still a scripting language, and in a way any scripting language can borrow that philosophy.

Squeak Smalltalk

[RevAaron]

I know people won't be into this, considering the crowd here, but all the same:

I use Squeak Smalltalk as my cross-platform toolkit of choice. Squeak includes a cross-platform GUI toolkit, as well as a cross-platform language, IDE, runtime and configurable world of libraries. Once you get out of the rut of Tk, GTK+, etc and get used to the programming style, it makes so much sense, it's almost scary. I was doing Python+(Tkinter or wxPython) before Squeak.

What most people here will gripe about is that Squeak's GUI system, Morphic can't be called from C, C++ or Perl at this point. It's possible, but so far our users have been happy enough with Smalltalk not to move away from it. Squeak also has it's own UI look and feel- it's not Windows, Mac OS, or GTK+ in appearance. I may be in the minority, but I prefer a clean look to poorly emulated widgets. By default, the look and colors are a bit kidsy, but like everything in a Smalltalk system (ala emacs, but easier!), it's very configurable.

Squeak supports a lot more platforms that most of the combos mentioned here. Right now, Squeak supports: Mac OS X, Mac OS Classic (System 7 - OS 9; m68k and PPC), Windows >= 95, DOS, WinCE (StrongARM, XScale, MIPS, SH4), X11 on any modern Unix-like, Linux framebuffer (Linux PDAs and kiosks), SDL (lending support to PicoGUI and others), OS/2, and the Acorn RiscOS. It also runs on bare hardware on stock x86 machines, complete with drivers written in Smalltalk. There might be more, but that's should be most of them.

No, I would reccoment it to people who are wanting to create a business app for a homogonized work environment, but it has many uses.

How does Qt acheive its system native look?

[E-prospero]

Since you seem to know about Qt on Windows/Mac, I'll ask here...

Sure, Qt can be used on Unix, Windows or Mac, but how does it achieve the native platform Look-and-feel? From the screenshots, it appears that there is are Windows and Mac themes, but how does it achieve this theme?

Does it:

1. Draw a theme that "looks" like windows, with behaviour managed by Qt
2. Use system native drawing routines to draw widgets that look like native widgets, but whose behaviour is still managed by Qt
3. Use system native widgets (actually create an MFC button), gaining the look AND feel of the native platform

Swing, and the "redmond" theme of GTK+ do (1); even these well maintained toolkits miss minor details in their rendering of system native widgets, so they end up just looking wrong. In addition, the interactions with menus, buttons, etc differ in subtle ways from genuine system native, making applications built using them respond in an unexpected manner.

From what I can make out, the nativeWin theme for GTK+ does (2), so it should look right, but it will still feel alien.

The only toolkit I can think of that does (3) is wxWindows. IMHO, this is the best solution, as it ends up with a genuinely platform native look and feel. However, I haven't ever programmed with wxWindows, so I can't comment on it as a toolkit in practice.

Under unix (1) doesn't really matter, because there IS no "system native"; as long as all your apps use the same toolkit, (vis, Gnome or KDE), you don't end with apps that feel wrong.

So - Which category does Qt fall into? Does anyone know of any other multiplatform toolkits that fall into category 3?

Russ %-)

Re:How does Qt acheive its system native look?

[e8johan]

http://doc.trolltech.com/3.1/qstyle.html

I'd say 1 (and perhaps 2). Remeber that it is possible to configure Qt to a windows look in a X Windows environment, so I'd go for 1. If you really need to know: read the source or ask trolltech (they are usually friendly and quick to reply).

Re:How does Qt acheive its system native look?

[Arandir]

I don't know about Aqua, but under Windows Qt does not use the native widgets. It uses the GDI instead, in the same way that it uses Xlib under X11. Using these basic drawing tools, it creates its own look. The QButton class draws itself, and is the same identical file under all platforms. So it can't be using native widgets.

It gets them right simply by drawing them right. 'Nuff said. It's really not that hard when you look at it.

I've got a couple of applications written with Qt, and they look like native Win32/MFC apps under Windows. You can't tell the difference, except that they use slightly fewer CPU resources. Throw a Liquid, Keramik or Qinx theme at them under NIX, and they don't look like Windows anymore.

Re:Different paradigms, different toolkits

[Anonymous Hack]

Idiot. AWT uses native widgets. And Swing could be made to look practically identical to the native OS. It's all about how you draw the widgets and there's not much stopping Swing from getting it pixel perfect.

Except when you introduce "themes" a la 99% of X users or more and more Windows users (as XP is adopted). This renders Swing more or less useless if you want the application to blend in to the rest of the windowing system.

Additionally, Swing is still all tied up in The Way You Code It. We have an application that uses Swing but we have to force it to use the Metal/Steel/whatever-it's-called look-and-feel because we had expanded the widget set to do various other things that just Didn't Work when they were in the Windows look-and-feel. This is the reason why i coded it in AWT first, because it was supposed to run on Windows, but because Sun never fixed the bugs (i think there are still plenty in their bug database i entered that are still open or ignored) we had to convert to Swing... and now we have a weird-looking app for both Windows and X users.

One of the KEY problems in GUI development that i see is fonts. Fonts are fucked up and all different between the windowing systems, and this was precisely the reason why we needed to implement our own widgets in Java. The names of fonts are different, the sizes they are are different, the way they're rendered is different... Yuck. We ended up having to make a flakey, probably illegal font pack for Linux, made up out of MS fonts, just to use Linux as our development platform, and even then they didn't render exactly the same (especially when we needed a widget to be a specific fixed width). From what i understand, MacOS does it different all over again. This is even a problem in supposedly cross-platform HTML too. Fonts just suck.

I could go on forever about this, about how GTK applications look like shit under Windows (they don't "refresh" or "paint" properly for starters), most every client app written in Java that's more complex than a JDBC form looks weird under Windows, ugh. I think the original poster is conceptually correct in what he was saying. Unless MacOS, X and Windows all start using a common method to implement themes and font rendering, cross-platform GUI development is going to continue to be utter hell.

Re:The web?

[0x0d0a]

It's okay. MS is putting all those complex technologies into rendering the current Start Menu.

Yes, but...

[FPhlyer]

In order to achieve the cross-platform compatability between gnustep and cocoa, you have to code on the gnustep platform. Apple has added much to make cocoa differ from the original openstep specification. So taking gnustep and compiling it on cocoa works fine... but not so the other way around!

Central problem of GUI programming

[Latent Heat]

The central problem of GUI programming is how to transmit that an event has occurred in once object (such as a button being clicked) to another object (of a class representing a containing form). It is not about objects but about relations among and connections between objects.

The low-level Windows API solution is the each object has a window handle and the interface that goes with that -- a WinProc. That means every window object has to expose the same, complex interface with a zillion Windows messages to every other window object it can come in contact with. This leads to (what some people) consider ugly -- the Giant Switch Statement in C implementations or those even uglier message map macros for C++ MFC (I believe wxWindows uses message maps too).

The Grand Quest is some simple mechanism for making direct signalling connections between objects without breaking encapsulation -- exposing the inner workings of every object to every other object: kind of like how to be on the Internet and disclosing your e-mail address without losing your privacy or worse.

The solution is to create some bridge class -- a courier with a personal knowledge of the recipient but a courier which publishes only a very generic interface to those seeking to contact the recipient. In Delphi that courier is an event type, in Java, it is an inner class with an ActionListener interface, in C# it is a delegate.

Qt has this mechanism called signals and slots, and to pull it off they had to extend the C++ language with this macro processor called MOC, and this has the BVDs bunched of C++ purists because they are in effect extending the language.

Qt nativity

[Earlybird]

The answer is #3.

On Windows, Qt uses native Win32 widgets and is fully integrated into drag/drop, clipboard, keyboard shortcuts, standard dialogs etc. Applications built with Qt, such as Psi, the excellent cross-platform Jabber client, feel perfectly native.

On Mac OS X, Qt uses the Carbon APIs and therefore looks and feels native. However, the Mac GUI is different from Windows and Linux in several ways, most by convention, such as the placement of the menus, window resizing icon, button placement, icon look etc. Psi, for example, looks okay on OS X, but its default theme's choice of colours and icons makes it stand out like an eyesore among the slicker Aqua apps. However, it's definitely possible to create a Qt app that follows the Mac design guidelines and therefore looks and feels perfectly native.

On Linux, Qt is the native widget provider.

Swing isn't particularly good cross platform

[g4dget]

Yes, I know, Sun wants Swing to be cross-platform. I was really hopeful when it came out. The first few years, it looked like Sun was going to make it work and work out the kinks. But after several years, it's clear that they won't be able to do that any time soon.

Swing still really falls short compared to other cross-platform offerings. In particular, performance and correctness of Swing on X11 and Macintosh are iffy: for example, window management is broken on X11, antialiasing makes lines disappear on Macintosh, and graphics can crawl to a halt in the presence of transparency on both X11 and Macintosh.

Another problem is that Swing is, as you point out, only "free as in beer": it's not open source and there is no open source implementation. Sun could, at least in principle, pull the rug out from under you at any time, for example, by starting to charge for commercial applications. And I recommend that you read the JRE license very carefully--it already comes with many strings attached (e.g., Sun reserves the right to install software on your machine).

If you need to write cross-platform prototyping code, Swing is OK. However, something like wxPython is probably both a bit easier to use for prototyping still and works somewhat better across platforms.

If you want to write professional-looking, robust, and efficient cross-platform applications, Swing is not the answer, at least for now. Programming in something like wxWindows or Qt may be a lot more work, but at least you can get the job done.

Experiences with FOX, Cocoa, Swing, FLTK, etc.

[zefnd]

First, a shameless plug: I'm working on a couple of C++ applications that are currently using FOX for the GUI (and other parts). The first one is a front end to the open source stats language R and it is called Obversive. This is the most active project, but it is still real tiny. The second project is a little chat client I'm writing called Bombyx which will work on the SILC and hopefully IRC. In addition to Bombyx, I've also developed a little GUI generator with Lua that makes FOX widgets pretty quickly. It's called GIG and you can get it from the Bombyx site mentioned previously. The intention with GIG is to make it work for any toolkit, but right now it does FOX only.

When I was working on these projects, I went through a huge number of toolkits and actually tried developing fast "mock-ups". My test was to see if I could get the first window I wanted in each project using available resources. If that worked, then I would try a couple of other windows. I also reviewed the designs of each and then went with what worked best at the time.

Here's my review of each of the toolkits I used. These are just my opinions, but they are based on actually using them in various platforms (or trying to).

FOX After all of this evaluation, I found that FOX was pretty much the best at the moment for clean, simple GUI building. It has pretty good docs (way better than wxWindows), and is fairly natural for coding. It also has some nice language bindings for various languages like Python, Ruby, and Eiffel. It doesn't have quite as many controls as wxWindows, and it doesn't work natively on as many platforms, but it is much easier to build and work with and much smaller. If you are porting a Windows application to another platform, you will probably be better off with wxWindows since they try to mimick the API design as much as possible (and of course, all it's problems too). Also, if you hate macros then you'll have a problem with FOX (and wxWindows too). A testimony to how easy FOX is comes from Obversive, where one developer had no C++ or FOX experience and has already created several complicated controls. Another developer has good C++ skills, but only worked with KDE previously. He not only developed an excellent Twin Table control, but also added lots of great features to it and in very little time.

FLTK I did the original work on Bombyx with FLTK. FLTK is a nice library, but it was just missing too many widgets to be useful. It was also rather buggy and it was a real pain to do delegation. There are, however, two really nice things about FLTK: no macros, excellent GUI builder. One of huge problems with ALL other toolkits I've ran into is that, when the developers start to make their GUI builder, the decide they need an entire IDE. I already have one thank you. I doubt some OSS project is really going to out-do my tool chain right now, especially if it's also working on the widgets. Just give me a simple builder please. FLTK got it right with FLUID--their GUI builder. It's real easy to use, super fast, and does one thing well: build interfaces. It was a little weird at times, but I checked out the latest and it worked great. Also, FLTK does not use macros for messaging which is nice for the C++ purists.

Cocoa I love Cocoa, but, Apple made a huge mistake by making it a MacOSX only beast. I think Apple could rule the world if I could spend my time writing my apps with a nice UI, great tools, and an easy language (Objective-C), and then click a button and have a Windows, Linux, HP-UX, and Solaris binary. You could do this with the original NeXT stuff, but Apple crippled Cocoa and friends. So, I reserve Cocoa for other useless programming that I only do on my MacOSX. There is GNUstep, but I couldn't get anything to work with it, and half the fun of Cocoa development is using Interface Builder (IB). BTW, IB is another GUI builder that is excellent, and also does just GUI building. Let's hope the wxWindows guys figure out this pattern and write a small GUI builder rather than their entire IDE which nobody seems to be able to compile but three dudes inside the cabal (sorry, it really burns me).

wxWindows I must say that wxWindows has a ton of nice widgets (I may steal their HTML widget) and works on a huge number of platforms. But, I kept getting burned in three areas: docs, dependencies, and bugs. Their docs are horrible. You have to hunt around the net looking for tutorials which are not very good anyway. Half the example applications in the distro don't even work so you can't rely on them, and it's just really hard to figure out what to do. I also hated having to add a billion other libraries to my build just to get wxWindows to work. I found it a problem when linking my application took longer than compiling all the files from scratch. Finally, just about everytime I went to use some widget, I found some bug or limitation that made it unusable. They have improved quite a lot from what I have heard, and people really rave about it, so I think everyone should give it a try. One thing also that annoyed me about wxWindows is that it does not support delegation very well. All the other toolkits I used either support delegation easily or practically require it. In wxWindows, I spent the better part of a week just trying to get one simple delegation design working and couldn't do it despite lots of help from people on various IRC channels. To me, things are broken if I have to subclass every time I want a widget. The wxWindows XML based resource files are supposed to fix this, but I won't hold my breath.

JFC/Swing The original version of Obversive was done in Swing with lots of other goodies. Java is my primary work language, and I really wanted to use it on the Obversive project, but we just kept running into performance problems. Frankly, Swing is just a P.I.G. and is really hard to code. None of the GUI builders available we tried proved to be that useful, and eventually we dropped it becuase it was just too huge. Ironically, we were able to prototype an almost complete GUI using FOX which runs on Linux, *BSD, Windows, and MacOSX (through the XDarwin or Apple X ports) in about 3 weeks time. This was mainly in part due to the slick design of FOX and simplicity, and partly in part because of the GIG code generator I put together. Oh, and we looked at SWT, but balked at the Linux or Windows only (and the fact that the flagship, Eclipse, ALWAYS crashes on Linux does not make me happy).

So, that's my experiences with these toolkits. I hope that helps answer the question, and I hope the reply wasn't too long. To summarize: Use FOX if you need C++ and good design. Use wxWindows if porting from MFC or if native controls are important. Use Swing if speed is not a problem, but cross platform really is. Use Cocoa if you only care about MacOSX and need to get something out quick. I actually prototype some UIs in Interface Builder on MacOSX, which says a lot.

I would keep an eye for stealth patents

[SgtChaireBourne]

Until there is a written, legally binding agreement or guarantee that Mono is free from encumbering patents, it's best to keep at a great distance. Or else you risk ending up with far worse problems than we had with the GIF format when UNISYS decided to uncloak their patents. With Mono, Microsoft would be holding the leash. Then again, this is a company that has a hideous track record with binding agreements.

It would seem to me that the whole reason for .Net was to port vendor lock-in to new platforms in case Windows died and also to try to compete with Java. Now that Microsoft is being forced to stop distributing a sabotaged variant of Java and to instead distribute Java as specified in the original contract, Java is even more useful.

Re:I would keep an eye for stealth patents

[truthsearch]

ABSOLUTELY RIGHT. (I'd mod instead of post, but I just used up my points last week!) The core of .NET plus the C# language being accepted as ECMA standards will be rendered useless if MS later uses patents force licensing fees or restrictions on developers. ASAIK nothing in the core or the standards themselves is patented, but things within other basic libraries are. Since none of the "higher" libraries are standardized, they can change at any moment. The forms for example can be implemented by Mono, but since it's not a standard MS can change their APIs at any moment and still claim "open standards compliance". Once everyone's dependant on the common non-standardized APIs implemented by MS and others, if they pull tricks like changing the APIs or enforcing patent licenses we'll again have segmentation and implementation reliance. MS will play that card if they see too much of a threat.

While the technology seems promising, we must be weary due to patents and corporate strategies. It's better to stick to non-corporate-backed open technologies in general. I personally like wxWindows for a native look-and-feel cross-platform object library. I'm fascinated, though, by the Mozilla platform as a way to serve GUIs from servers and to have apps centered around a rendering engine.

Qt does not support all of C++

[josse]

I have been using Qt for the last 1.5 years to develop an application for post-processing of segmented (medical) image data as part of my master thesis. The application is available under the GPL at sourceforge

During development one major disadvantage of Qt has surfaced, and I think it shows that the Trolltech has choosen a terribly wrong solution to a complex problem.

In order to support their signals-and-slots mechanism (which is an elegant concept, and allows for easy implementation of both the model-observer pattern and the mediator pattern) they have added two new keywords to the language, namely signals and slots. In order to support these you _HAVE_ to run a preprocessor called moc (Meta Object Compiler) for your program to link. But moc does not support templates.

Mostly we have managed to work around this limitation by having a non-template superclass which declares the signals and slots (luckily slots can be virtual) and then have the template parts in a subclass, but this leads to unnatural class hierarchies.

Other libraries have managed to support a signals-and-slots mechanism without such an ugly hack. Both Boost.signals and libsic++ implement them. However their syntax is not as nice as Qt's. If C++ really need even more syntax is of course another question :-)

While not all applications rely upon templates, they have some interesting uses, and if an applications first starts to use them, most classes easily ends up as template classes. See the book Modern C++ Design for "new-school" uses of templates. This could easily be the direction C++ development is headed, and it's a shame Qt will not be able to be a part of it.

Re:Qt does not support all of C++

[elflord]

During development one major disadvantage of Qt has surfaced,

The alternative you're so enthusiastic about also has a "major disadvantage".

and I think it shows that the Trolltech has choosen a terribly wrong solution to a complex problem.

No it doesn't. It shows that you don't understand why they chose to design it that way. The loose coupling between componenents is a feature. The dynamic object model used by Qt is a feature.

Mostly we have managed to work around this limitation by having a non-template superclass which declares the signals and slots (luckily slots can be virtual) and then have the template parts in a subclass, but this leads to unnatural class hierarchies.

Hiding parametrization is a necessity if you need to support a dynamic object model. There's nothing "unnatural" about having a superclass for a family of template classes. Doing this sometimes is a useful way of hiding template code, and reducing code dependencies between translation units.

Other libraries have managed to support a signals-and-slots mechanism without such an ugly hack.

Using a different ugly hack instead. How do you dynamically load objects using the boost/libsic++ template model ? It's a more static model, and that has its disadvantages -- code is more tightly coupled (because classes need to know more about each other), and you get all the usual template overhead. Qt behaves much like an interpreted language, it is very flexible. You lose that with a static template model.

While not all applications rely upon templates, they have some interesting uses, and if an applications first starts to use them, most classes easily ends up as template classes. See the book Modern C++ Design [amazon.com] for "new-school" uses of templates. This could easily be the direction C++ development is headed,

Templates are useful, and they're certainly helping give speakers/writers something to talk/write about. But the world is bigger than templates. They are powerful, and useful if used judiciously, but the thought of trying to actually compile an application where most classes "end up as tempalte classes" is fairly scary. Templates are a powerful tool, but the power comes at a price. Simply put, one should not claim that "the answer is templates" without first understanding what the question is.

Do you bet part of your quality of life on Java?

[Futurepower(R)]

Remember Pascal? At one time, Pascal was the major development language. Pascal was taught at all the universities. But, an amazing thing happened. In a period of about 4 years, Pascal died. Hundreds of thousands of people had spent millions of hours learning the particular quirks of Pascal and of Pascal compilers. All of that time was lost.

If you have never lived through the loss of a major direction in your life, you may not even realize it can happen. The people saying I'm a troll in this thread probably haven't seen technology die.

Remember Powerbuilder? At one time there were about 1.5 million active Powerbuilder programmers.

No really, is Java dying? Now, I'm seeing, or think I'm seeing, the same thing with Java. The expected energy and support and standards have not appeared. Or have they? If I'm wrong, prove me wrong; I would like Java to be a success, that would simplify my choices. We bet part of our lives on our choices of specialization.

What frightens me is that there is so little support for GUIs in Java. When programmers don't work to improve their tools, they are consciously or unconsciously deciding that the technology does not warrant improvement.

I've seen Java programs that are unacceptably slow.

Sun mismanagement of Java makes people look elsewhere. The world is beginning to realize more fully that proprietary means, "I'm a dog on a leash; I'll bark whenever you yank my chain; please abuse me."

When you use Java, or any language in a way that is not fully compiled to native instructions, you give away your source code. Sure, what you give away is without comments or variable names, but nevertheless you may give away important routines. That's fine if you intend to make a gift of your work to the world; you should have the option not to do so. There has been surprisingly little work on full Java compilers; until Java has acceptable compilers, it hasn't proven itself. Is GCJ mature?

Visual Basic and Perl are written in C. Should it bother me about other languages that they are written in C or C++? Why not eliminate the middleman? Can an acceptable result for application development be achieved using something like Boundschecker and avoiding pointers and using automatic garbage collection where appropriate?

Slashdot has a moderation problem. You can't comment on and moderate the same story. So, moderators by definition moderate stories that don't interest them much.

Bet wrong and go back to being a novice. As I write this, the parent post has been moderated Flamebait=1, Insightful=1, Overrated=1, Total=3. The question is a real and important one, not a troll. When you pick a technology, you lose part of your quality of life if you are wrong; you go back to being a novice at something else.

If you know better, educate me. If I'm wrong, and you know better, educate me. That's the entire purpose of Ask Slashdot.

My vote is for wxWindows

[raboofje]

Not only is it stable and complete, I'm pleased that wxWindows is under ongoing active development in the Open-Source tradition.

The mailinglists are, though high-traffic, very informative and the atmosphere is friendly (hardly any flames, 'dumb' questions are usually anwered with 'check the docs at ....' instead of 'RTFM, you dumbass').

Though the bulk of the wxWindows code is written by a small group of core developers, the development process is very 'open': decisions are often made based on discussion on the mailinglists, and patches usually well-appreciated.

As with QT, wxWindows is also very much worth considering when developing single-platform or even non-GUI applications (check out the wxBase port).

Re:Different paradigms, different toolkits

[joto]

This would be very informative, if it wasn't for the fact that it was all wrong.

And I mean it. You would probably be hard pressed to find even one correct sentence here. For those interested, here are a couple of refutations.

X is based on a networking concept where anyone can access anyone else's screen as a network resource.

Wrong. Only those with permission can access it. But that would be programs, not people. For people to access the screen, they would have to physically be there, and that is no different than any other windowing system.

This leads to multi-threading issues as it is possible for two people to use the same desktop, even same application, simultaneously

Wrong. While many people can sit in front of one computer if it's enough space for them, that doesn't mean anything will be more multithreaded. Also, the display server will have to do exactly the same kind of resource multiplexing as it does on windows (whether the apps displaying windows are executing remotely or locally is of little difference, they are still in different threads and usually also different adress spaces).

As a result, toolkits that have their origins in that environment like GTK and wxwindows have strong multi-threading support not to mention strong networking support.

Wrong. Few, if any, X11-toolkits support multithreading. This is a direct result of the age of the X11 core libraries, which themselves does not support multithreading. Most everyone agrees that this is a bug, but it's also one that's hard to fix.

OTOH, Windows was built around a single user concept, which from a networking perspective is more secure because a person's desktop isn't a networking resource (but that's neither here nor there).

Wrong again. How do you think those Citrix farms work? Windows isn't built around a single-user concept any more than Unix is (I am talking about NT/2000/XP of course). It might be the case that your typical windows distribution is only useful for one user at a time, but the underlying technology very much supports several users. As for not exposing anything on the network, sure that makes it more secure. Nobody in their right mind allows X11 through their firewall. But windows has plenty of other security holes.

This results in the base windowing subsystem's reliance on processes as the fundamental object of execution (as opposed to threads).

Again wrong. XFree86 uses a simple request-response loop (no threads or processes). There do exist multithreaded X-servers however, but not for the reasons you say. Mainly, if they are multithreaded, it is purely for performance-reasons.

Whether processes or threads are used, have absolutely nothing to do with networking, but more to do with taste, and programmer preference.

As for windows, it uses threads. Lot's of them, so even there, you are wrong.

So toolkits built upon Windows (MFC, OWL, QT) are able to harness Windows's windowing support in a way that more easily and effectively takes advantage of the features of the subsystem.

I fail to see any correspondence between the "cause" and the "conclusion" here. In any case, it is wrong. On the other hand, windows is a more mature and stable GUI platform. And this is more than enough to explain why X11 GUI's generally suck in comparison (even when they are cross-platform).

Attempting to port one toolkit from its home platform to a foreign platform leads to problems of "look and feel". AWT and Swing are prime examples of toolkits that look strange whereever they are used. Likewise, wxwindows feels funny running on Windows and GTK looks funny. Hell, MFC doesn't even run on X.

True. However, MFC apps can (more or less) run on X11, if you want to pay enough for it, and you really need it. There are companies selling that sort of thing.

What this all boils down to

Well, the only thing it can boil down to, is that either you are a troll, or someone seriously likely to talk out of his ass about anything he doesn't know about.

The final "conclusion" is obviously right, but I fail to see why you needed all the errors above to "support" it.

A lot of answers to the wrong question.

[viktor]

As I read the question, it was about a cross-platform toolkit with native look-and-feel. I definately interpret this as being native to the platform where it's run, not native to the toolkit! Otherwise the statement would be meaningless.

The discussion has, as usual, talked a lot about Tk, which has it's own look-and-feel and therefore certainly not is native. Qt is cross-platform, with applications that look native, but necessarily aren't.

There's more to a platform's look-and-feel than how the buttons look. The location of the menu-bar is one example. The placement of OK/Cancel buttons another, and standard quick-keys a third. Mac OS X has GUI guidelines which specify how far apart different controls should be, and they are almost guaranteed to not match KDE's guidelines.

Mac OS X/Cocoa also has the concept of sheets, which are basically modal dialogs attached to one certain document window in an application. There's no similar concept in e.g. Gnome, and a toolkit would therefore be hard pressed to find a replacement within the native look-and-feel. In fact multi-document applications in their entirety are differently handled on Windows, Linux and Mac. And I don't even think Gnome and KDE agree on all details of look-and-feel.

Cross-platform with native look-and-feel is therefore a lot more complex than just using Qt or Tk. What would really be needed is actually a way of abstracting away the GUI part of an application entirely, basically making the entire presentation into a Stylesheet of sorts, somtehing like what you do to strings and numbers for i18n/l10n.

But I haven't seen any real efforts to do this. It might work without it for Linux vs. Windows, because neither have very strongly enforced standards on look-and-feel, and you can therefore get away with doing things almost right (or even doing them wrong).

Re:A lot of answers to the wrong question.

[spitzak]

Mac OS X/Cocoa also has the concept of sheets, which are basically modal dialogs attached to one certain document window in an application. There's no similar concept in e.g. Gnome,

Actually both X (or X Window Managers) and Windows support the idea of "child" windows that belong to a certain parent window. In fact this is about the only way to keep one window atop another. On both systems hiding the parent window makes the child window disappear, and showing it again makes the child window reappear. Also (for Windows and most X window managers) the child windows have no iconize buttons of their own and cannot be iconized seperately. Sheets match pretty cleanly onto this.

MFC dead

[edxwelch]

For anyone starting a new project from scratch I would advise not to use MFC as this product is being discontinued. Bug fixes will still be released, but no new features. The product manager of Visual.NET has stated that fact here (if you read between the lines): http://www.codeproject.com/interview/nickhodapp140 22002.asp For a new project it's much better to choose a library that is seeing real improvement in each release, like QT from Trolltech.

From a starter's point of view

[xynopsis]

I would just like to point out my experience from using QT for the past two days. It was very nice and straightforward to learn. I am trying to port my old motif-based application to QT and so far I have made some real progress after a day of reading the documentation and tutorials. In the field of widget interaction, QT's signal and slots model really rocks compared to callbacks (GTK still has callbacks). No more trying to double check your callback's parameters to see if it matched the calling widget and get screwed in the process.

Creating custom widgets too is a pure pleasure - subclassing really is a gift!
...Just some of the nice things you get with QT not to mention you get a free excellent GUI desinger plus excellent documentation.

MFC for cross platform?

[Spunk]

Isn't that like a bar that plays both types of music: country and western?

QT Rocks

[WPIDalamar]

We've been using QT for Mac & Windows for a while now, and it rocks!

Also, if you're looking for a job doing QT development, we're hiring!

check out
http://www.tomsnyder.com/about/au_work_depts.asp?D eptID=PROD

I'm the source of the original Ask-SlashDot....

[rrwood]

I posted the original question about cross-platform GUI toolkits, for whatever that's worth.

After much investigation, I've concluded that they all suck a little bit in different ways, and that there is no absolutely "right" answer. Since each has strengths and weaknesses, you have to look at the platforms you are trying to hit, and choose accordingly.

That said, I have to say that Qt is very nice in terms of its polish, documentation, user community, and support of Mac OS X, Windows, and X. The only downside I see there is that they emulate the look/feel on the target platforms, rather than using native widgets, and they don't support Mac OS 9.x and earlier.

For my project, my choice is wxWindows, which uses native widgets and supports Mac OS 9.x as of the latest wxWindows stable release. wxWindows has a great user community, has reasonably okay docs, and is pretty simple to get up to speed with.

Oh-- one other option that I have not investigated for a long time is CPLAT. It also looks quite nice for all the same reasons as wxWindows, though CPLAT is far less well known.