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

Swing

[Tom Davies]

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

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.

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.

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.

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 ?

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

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.

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

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