Slashdot Mirror
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?
Seriously, the question wasn't limited to C/C++, which brings lots of other baggage besides teh GUI.
Swing is functional and cross-platform, free-beer, and widely understood.
I have discovered a wonderful
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.
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.
The biggest difficulty in creating cross platform toolkits is resolving the different paradigms inherent in each platform.
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.
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). This results in the base windowing subsystem's reliance on processes as the fundamental object of execution (as opposed to threads). 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.
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.
What this all boils down to is that cross-platform development is always going to have limitations because the roots of each toolkit will decide its look and feel as opposed to the platform itself deciding the look and feel according to the platform's native interface.
I have been pwned because my
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.
Swing and AWT often provide poor GUIs. Java is often slow. Sun involvement makes Java a proprietary technology. Is Java dying?
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.
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.
What I noticed first about wxwindows is that it is a clone of MFC through and through. Even down to the message pump, it is almost identical to MFC in every way except for the method names.
As a former MFC maintainer (feel free to boo and wing tomatoes) with a huge interest in GUI toolkits personally, I took a look at wxwindows. At least for the Windows portion of the wxwindows code, the toolkit offers no advantage over MFC. It is at a slight disadvantage actually because it lacks many of the feature classes (wx supports most of the basic classes) of MFC.
You can get native widgets, but since people on Unix and Mac and Windows all have different ideas about what an application should be like, the "feel" aspect of the application will always be wrong on at least one of the target platforms.
This is not about the window itself, but about the placement of buttons within the window and the fonts used and the way things are laid out. The worst UIs usually come from people who develop for Unix because they are used to so much less adornment in their apps as a result of their natural operating environment.
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 ?
Yes, but doesn't it make a difference that WxWindows is:
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".
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!
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:
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 %-)
... and never, ever play leapfrog with a unicorn.
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.
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.
What did you eat today? http://www.atetoday.com/
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.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
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.
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).
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).
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.
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).
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.