Cross-Platform GUI Toolkits (Again)? 517
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?
Visual Basic! (Score:4, Funny)
I hate BASIC as much as the next guy (Score:2)
If you really do use BASIC, I recommend RealBASIC [realbasic.com] for Mac OS X. I could never stand it for serious development, but it's a lot better than VB with features like syntax formatting to make lame code easier to read.
I used it to throw together a custom client for my Fortune [frob.us] page for all the lame OSes in a few minutes. BASIC is still easy to look down upon and all implementations are seriously lacking in vital(at least to me) areas. RB doesn't have UDP support, and VB doesn't have syntax formatting.
Back to the serious topic and away from replying to a joke: Java's SWING toolkit is my favorite multiplatform toolkit. A single binary works for most platforms, and "advanced" features that we don't consider necessary in disagreement with our respective (former
For quickly drafting small projects, PHP and other server-side scripting languages are a great option. I would love to be able "throw togethor" something like this as well as package it into self contained binaries for winshit and OS X.
Re:Visual Basic! (Score:2, Funny)
Maybe not so funny.
Re:Visual Basic! (Score:5, Informative)
Re:Visual Basic! (Score:5, Informative)
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 [opera.com] and Psi [affinix.com].
FLTK (Score:5, Informative)
Re:FLTK (Score:5, Informative)
Re:FLTK (Score:2)
Re:FLTK (Score:3, Insightful)
vanity? (Score:2)
Users will judge a product based on how it performs, and (hopefully) not how it looks.
Re:FLTK (Score:3, Informative)
As for the menubar at the top of the screen, you just have to use the Fl_Sys_Menu_Bar widget.
Re:FLTK (Score:2)
For instance, I wanted my program to use TCP/IP (regular bsd calls: socket, accept, recv). I used Fl::add_timeout [fltk.org] and Fl::repeat_timeout [fltk.org] to check the incoming buffer every few seconds (no need for high data rate).
That worked great- unless I made some call like fl_file_chooser [fltk.org], which blocks until it returns. Then the timeout function won't happen until the dialog box is done- a fact completely ommitted from the documention.
I suppose I could dig into the source code (it is LGPL after all) and try to fix it, but things like this don't inspire confidence.
Swing. (Score:2, Insightful)
Re:Swing. (Score:2, Insightful)
And Java doesn't bring lots of baggage?!
kinda ironic (Score:3, Funny)
Well, what about .NET? (Score:2)
I keep hearing about how .NET speeds up development work--how exactly? (Sorry, I'm a perl/c/db/vi programmer and haven't touched .NET's GUI toolkit, yet).
Re:Well, what about .NET? (Score:4, Informative)
Cocoa or GNUstep (Score:5, Informative)
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.
Yes, but... (Score:4, Informative)
Swing (Score:5, Insightful)
Re:Swing (Score:4, Interesting)
Swing isn't particularly good cross platform (Score:3, Insightful)
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.
Re:Swing (Score:3, Insightful)
Re:Swing (Score:3, Insightful)
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 (Score:3, Informative)
Re:SWT using Eclipse (Score:5, Insightful)
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 (Score:3, Insightful)
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... (Score:5, Informative)
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... (Score:3, Interesting)
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... (Score:3, Interesting)
Eclipse (Score:5, Informative)
A few glitches in the Linux version... (Score:5, Interesting)
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... (Score:2)
Yeah, they're really hurting the community by replacing proprietary Swing with open-source SWT.
The fragmentation is a little disappointing, though.
Re:A few glitches in the Linux version... (Score:5, Informative)
Re:Non-AWT/Swing GUI toolkits and Certified Java (Score:2)
Tcl/Tk is the past and future king (Score:5, Insightful)
nonsense (Score:5, Interesting)
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:Tcl/Tk is the past and future king (Score:3, Interesting)
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 (Score:4, Insightful)
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 (Score:5, Insightful)
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 (Score:3, Interesting)
X-Platform GUI Toolkits (Score:2, Funny)
Different paradigms, different toolkits (Score:2, Insightful)
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.
Re:Different paradigms, different toolkits (Score:3, Informative)
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.
Re:Different paradigms, different toolkits (Score:5, Informative)
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:Different paradigms, different toolkits (Score:5, Informative)
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.
I would keep an eye for mono (Score:5, Insightful)
I would keep an eye for stealth patents (Score:5, Insightful)
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 (Score:3, Interesting)
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.
SWT (Score:5, Informative)
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 [eclipse.org] IDE.
Re:SWT (Score:2)
If so, can you compile it using CygWin?
Also, where is it documented?
I was looking at using SWT before I started the most recent project, but I had to decide quickly, and had no experience with it.
wxWindows (Score:5, Interesting)
Re:wxWindows (Score:5, Informative)
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 (Score:2, Interesting)
Qt all the way!
Re:Qt still wins (Score:3, Informative)
QT convert (Score:5, Interesting)
At my new employment I had a project that needed to be cross platform. I was itching to use Kylix [borland.com], 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.. (Score:5, Interesting)
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 [eiffel.com], it's free!
Kylix / Delphi (Score:3, Informative)
Here's the link with more info: Borland Kylix Open Edition [borland.com]
-My Karma ran over your Dogma
WxWindows? (Score:4, Informative)
What has been your experience with WxWindows [wxwindows.org]? The web site says that WxWindows provides a native look and feel on Windows, Unix, or Mac [wxwindows.org]. There are IDEs [wxwindows.org] and other tools.
Re:WxWindows? (Score:3, Interesting)
If Bill Gates decides to marry Britney Spears? (Score:3, Insightful)
Yes, but doesn't it make a difference that WxWindows is:
Re:WxWindows? (Score:4, Informative)
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.
Depends on the task (Score:5, Informative)
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 (Score:3, Interesting)
Central problem of GUI programming (Score:5, Informative)
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.
FOX (Score:5, Informative)
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 [fox-toolkit.org] for more info.
Re:FOX (Score:3, Informative)
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.
Is Java dying? (Score:2, Insightful)
Swing and AWT often provide poor GUIs. Java is often slow. Sun involvement makes Java a proprietary technology. Is Java dying?
Re:Is Java dying? (Score:2)
Do you bet part of your quality of life on Java? (Score:5, Insightful)
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 [gnu.org] 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 [compuware.com] 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.
Java / Swing (Score:2, Insightful)
User Interface design: "Information Architecture" (Score:2)
It seems that a fancy name for user interface design is "Information Architecture" [surfercentered.com].
Usability Links [surfercentered.com]
More Usability Links [surfercentered.com]
Site Critiques [surfercentered.com]
Why not native? (Score:2)
Or would the LCD of these three platform's toolkits not be usable in any way? Are they that inherently different?
Qt? (Score:5, Informative)
Trolltech's [trolltech.com] QT costs $1550 [trolltech.com] each, per developer, for commercial use on Windows and Mac.
QT versus Java (PDF file) [sarang.net]
QT versus MFC, in English [freehackers.org] (See the French below.)
QT versus MFC, in French (MFC contre Qt) [freehackers.org]
Re:Qt? (Score:4, Informative)
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? (Score:3, Informative)
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.
How does Qt acheive its system native look? (Score:4, Insightful)
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+ [neugierig.org] 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 %-)
Qt nativity (Score:3, Informative)
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 [sourceforge.net], 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.
Re:How does Qt acheive its system native look? (Score:3, Interesting)
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? (Score:3, Interesting)
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.
pyGTK is the EASIEST GUI toolkit (Score:2, Interesting)
Realistically this should not be an issue IMHO. (Score:3, Insightful)
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 ?
ZooLib has a native look and feel (Score:4, Informative)
-
http://zoolib.sourceforge.net/ [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 [sourceforge.net] 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 [goingware.com].
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 [knowledgeforum.com].
One person's analysis: (Score:3, Informative)
One person's analysis and comparison of GUI toolkits: Why this GPL programmer didn't choose
Excellent book.. (Score:5, Informative)
http://www.opendocspublishing.com/pyqt/ [opendocspublishing.com]
Python: cross platform
QT: cross platform, native-working widgets.
QT, however, isn't free for commercial use.
S
Squeak Smalltalk (Score:4, Interesting)
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.
Experiences with FOX, Cocoa, Swing, FLTK, etc. (Score:5, Informative)
First, a shameless plug: I'm working on a couple of C++ applications that are currently using FOX [fox-toolkit.org] for the GUI (and other parts). The first one is a front end to the open source stats language R [r-project.org] and it is called Obversive [sourceforge.net]. 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 [sourceforge.net] which will work on the SILC [silc.net] and hopefully IRC. In addition to Bombyx, I've also developed a little GUI generator with Lua [lua.org] 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 [fox-toolkit.org] 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 [sourceforge.net], Ruby [sourceforge.net], and Eiffel [sourceforge.net]. 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 [fltk.org] 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 [wxwindows.org] 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 [sun.com] 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.
Qt does not support all of C++ (Score:5, Informative)
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. [trolltech.com]
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 [boost.org] and libsic++ [sourceforge.net] 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 [amazon.com] 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++ (Score:3, Insightful)
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.
My vote is for wxWindows (Score:3, Insightful)
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. (Score:5, Insightful)
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. (Score:3, Informative)
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 for cross platform? (Score:3, Funny)
QT Rocks (Score:3, Informative)
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?
I'm the source of the original Ask-SlashDot.... (Score:3, Informative)
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 [ksoft.net]. It also looks quite nice for all the same reasons as wxWindows, though CPLAT is far less well known.
Re:HTML (Score:4, Informative)
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.
Jabbascript. (Score:3, Interesting)
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.
Re:The web? (Score:5, Funny)
Re:The web? (Score:4, Funny)
Trying to Answer the Original Question, v. 2.0 (Score:3, Informative)
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...