Slashdot Mirror
What 2D GUI Foundation Do You Use?
Zmee writes "I am looking to build a 2D application for personal use and I will need to use a canvas to paint custom objects. I am trying to determine what foundation to use and have not located a good side-by-side comparison of the various flavors. For reference, I need the final application to work in Windows; Linux is preferred, but not required. I have looked at WPF, Qt, OpenGL, Tcl/Tk, Java's AWT, and others. I have little preference as to the language itself, but each of the tutorials appear to require significant time investment. As such, I am looking to see what the community uses and what seems to work for people prior to making that investment."
FLTK (www.fltk.org) is still in active development and is my cross-platform toolkit of choice - C++-based, easy to use, and works on Windows, Linux, and Mac OS X with ports for other platforms available.
I print, therefore I am.
I have extensive experience using Qt under both linux and windows (5+ years), as well as WinForms. However, for the last year I've been using WPF and I think it's a dream. Granted, there are cons to it and if your bottom line is performance in all situations (e.g. this is a game) then I would avoid it. They talk a big game about high object counts, but it requires extensive virtualization and time and then it still might not work depending on what you're trying to do. That being said, WPF's use of binding is fantastic and if you do a little bit of homework on binding I think you'll be pleasantly surprised. Don't get me wrong, I love Qt (and C++ for that matter!). But for the amount of stuff I need to crank out, it's tough to beat WPF. One last caveat: I wouldn't count on Mono to bring your apps to linux. I've only spent a little time with mono, but unfortunately (in my opinion), the linux community seems to have largely shunned C#, .NET and all that goes with it.
I agree with this. Qt is seriously really awesome.
I've also used everything on the list (Java AWT, Swing, Gtk, C# & .NET Forms, WPF, OpenGL, WxWidgets, MFC, GDI+, etc) and nothing comes even close.
While some of the things on the list are pretty easy to use (arguably as easy as Qt), they lack something major (such is portability or speed for example). For example, I worked at a place where we used to write some apps in C# due to customer request - it turns out that we had to write several components in native C++, then export the interface to C#. That was the only way we could meet the speed requirements! So much for non-native languages...
Since version 4.x, Qt library has been modularized into different components (e.g. GUI, Network, XML, etc) and thus it is not bloated as some people are suggesting. A Qt GUI DLL is nothing bigger than WxWidgets one for example.
The catch is that Qt is a entire framework (something similar to Java Class Library or .NET framework) for building applications. So for example, if you were to use GTK or OpenGL for graphics, you'd have to use another library for threading and another library for network, XML, etc.
Qt has components for all of those things.
Oh, I also found that no other framework comes close to Qt when doing OpenGL. There are certain annoyances when programming with GLUT for example, but if you use Qt as a base for OpenGL, you just override couple of functions such are initGL() etc and you have an OpenGL application up!
It also has excellent tools and amazing documentation! Did I mention that its portable? :)
I initially wanted to use Qt for my latest project, but I'm rather concerned at the license which says you can't upgrade to a commercial version of the Qt license if you start the project as the free (beer) LGPL license. It makes no sense because a project may start off small, but then expand later.... and at that point, you can't then use the better (albeit expensive) full license. I moaned about the subject here:
.NET/Winforms/WPF looks ever more tempting.
http://www.qtforum.org/article/34891/licensing-issue.html
I'm hoping Nokia will adjust their stance on this issue, otherwise
Why OpalCalc is the best Windows calc
I second the parent post. However, in my opinion, OpenGL only is pretty tough to use. It takes a lot of knowledge. (GLUT can help to get you started.)
Where OpenGL would require you to program too much functionality from scratch, I personally recommend QT, using OpenGL only where you need it. QT is easy to learn, easy to code for, provides *tons* of functionality, and it performs great. In fact it performs well enough for very heavy 3D animation software to rely on it. (Maya has now been rewritten to use QT, and it is a big improvement.) You can paint your own custom anything, and even easily integrate 3D into your project. I really can't say enough good things about QT. It is now available under the LGPL, so you can use it for open source or closed sourced projects.
As mentioned above by the parent, QT isn't lightweight, but it isn't a pig either. You can use as much or as little of the toolkit as you like, and it can run very fast and have very low overhead. It is light enough that Nokia is using it as their primary development framework for mobile apps with their upcoming Meego based phones. From my personal experience QT flies.
Also, I've had great results with PyQt and with PySide. PySide is the new, "official" binding for QT on Python. They have examples in their demo folder of custom canvas based applications, and they work great and are easy to follow. You can have your own similar program, written from scratch in Python, up and running in 10 minutes.
It should also be noted that because QT works so well cross-platform, it has a huge advantage over toolkits that are tied to a single operating system. (Particularly those from MS.) In my own work, I won't even consider using something that doesn't run on Windows, Mac, Linux, and potentially more operating systems. I use all kinds of devices, and I don't want to be tied down. QT makes cross platform development straightforward, and software like Autodesk Maya is proof that it works even for highly complex projects.
I know I'm starting to sound like a salesman, but my experiences really have been that positive. About the only downside is that there aren't current C# or Java bindings for it. This doesn't matter to me though, because I've got C++ where I need performance and Python where I want ease of use. (With Cython, you can easily have performance and ease of use at the same time.)
I hope that helps.
As much as the parent comment looks like an ad, I've used Qt and can say that my experience matches what the parent said.
I use Qt Creator as my IDE and it's great with the Designer integration. It's not quite as full-featured in some respects to Visual Studio or KDevelop (Qt works with VS as well), but the integration with the documentation and preprocessor makes up for it.
And the key is of course the documentation. Qt's documentation is possibly the best example of what a doxygen-based documentation can look like. Every class has a multi-paragraph and in-depth description, and most even have one or two code examples.
Out of everything I've tried (pretty much everything usable from C, C++, and C#), WPF is the best UI framework around. It is extremely flexible and can be very intimidating if you try to learn all the details too quickly, but the basics of it are easy. You should be able to pop out a good design pretty quickly. It's a shame that Mono has no plans to implement it, because everything else feels primitive in comparison.
If you don't mind dirtying your C++ with a less-than-modern design and ugly preprocessor hijinks, Qt can be a pretty solid framework. Works well on many platforms and is full of features. Has a lot of portable non-UI things too, but I haven't used much of it.
Python's UI stuff is simple but has a lot of features. Great for quick, portable apps. Easy integration with C++ if you need it.
I avoid wxWidgets. The last time I tried using it (about a year ago), I ended up very frustrated rooting around their code to find that it makes a bunch of stupid assumptions about things like DPI, default fonts, etc. that fall apart pretty easily.
I also avoid GTK, but mainly just because it always feels "off" on Windows.
Hmmm... Where do I start. The "Python UI stuff" that you are talking about is probably tk. It's worth noting that you can use tk from many other languages besides python, python wasn't the first language to support tk, and tk isn't the only "UI stuff" that you can use in python. (For example, most of the GUI python stuff I've written has used Qt, which you imply requires working in C++.) For bonus points, you can even try to import Qt, catch an exception if that fails, and use tk to do your UI if Qt is unavailable on the system where you are running. All in one script, extremely portable, and nicer looking than tk whenever possible.
As for Qt in C++, as an application developer, I don't really care if the build system is a bit wonky. When I put on my architect hat, I can certainly say that Qt is a giant monstrosity that is very different from anything I would have created on my own. But, that sort of philosophical issue doesn't really effect anything when you are making an app.
QT and PySide for doing GUI with Python.
QT for C++
Personally I prefer Java + Swing. Add Java2D and you have everything you need. If you want it to look native, there's a way to do that. It will run everywhere Java is available and since you say this is a personal application you don't need to worry about end-user problems. Plus, if you ever want to get it to work on Android or Blackberry phones then you'll already have a head start.
I'd also recommend using SpringLayout, it's the simplest way to get things looking right.
Seconded. Swing is (despite what many people around here would like to believe) a very capable GUI library. It's by far the best object oriented GUI library I've come across, with a much more logical API than SWT, Qt, or GTK. Plus, Java2D for raw drawing is incredibly easy to use and it automatically gets hardware acceleration (OpenGL on *NIX systems) so the performance is good. Swing does have a bit of a learning curve, but there's excellent GUI builders for it (e.g. NetBeans) and the API really makes a lot of sense when you learn it.
If Java isn't your thing, Qt would probably be the way to go. I find the API a bit clumsier than Swing, but the major features (hardware accel, powerful 2D, and cross platform) are there. On the other hand, raw OpenGL has a comparatively huge learning curve and wouldn't have any sort of system look and feel. It would likely be the best performance-wise, though.
Thanks. It might be in the AWT package but if he was limiting yourself to only AWT then I suggest he's not considering the possibilities that Swing adds above AWT. Colouring the pixels on the screen is only part of it, you also need buffering and layers (the handy GlassPane) etc to do cool stuff (drawing with some of the concepts of 'Filthy Rich Clients'). Hence, I mention Swing as good for drawing above and beyond the confines of AWT.
What I forgot to mention is that you can mix OpenGL with a Swing canvas for your drawing (you need somewhere to draw after all) and it is pretty seemless thanks to JoGL. So, start with Swing technology and adding 3D over your 2D is very straightforward. While you can use JoGL with AWT it is again best integrated with Swing.
I would agree.
Investing your time into Qt is the best investment. Stick to C++ and Python. Both work.
Avoid Perl-QT though. Not that it does not work, but it makes your brain go numb because you end up writing in pidgin-C++ intersperced with Perl. It overrides perl default OO conventions and uses C++ ones. There are parts where you have to outright put C++ snippets into the Perl code to get it work.
Tk is also good, but obsolete by today's standards. Its one and only remaining use is writing UIs for Perl where you cannot use web ones.
Avoid GTK: Grave danger you are in. Impatient you are. Once you start down the dark path, forever will it dominate your destiny, consume you it will. Always write Yoda code you will...
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
I love the way people say this stuff about the LGPL.. have you ever actually read it? This is the bit you're probably referring to:
6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.
The newer version 3 of the license has more clear wording, which are actually more restrictive.. permitting modification of only the library not the combined work.
In either case, every time you say "you can link to LGPL licensed libraries without having to do anything!!" you're inviting people to violate the author of that library's license.. I'm sure they appreciate it.
How we know is more important than what we know.
I also avoid GTK, but mainly just because it always feels "off" on Windows.
I have heard good things about the FOX toolkit (http://www.fox-toolkit.org/). The Goggles Music Manager was written using this. Looks very Windows-ish on Linux, so I would expect it to FOX based apps to be comfortable for Windows users.
Don't try to out wierd me, three-eyes. I get stranger things than you, free with my breakfast cereal. --Zaphod Beeblebr
Easy, Good, Portable.
Pick two.
But seriously, WPF can now provide more than enough horsepower for some really flashy UIs - at the cost of portability.
I have had good success with wxWidgets on both Windows and Linux. That said, it's the *only* cross-platform GUI development library I have used and I am used to it. Rather than use anchors for placing window components it uses something called sizers which are a lot harder to work with until you get used to them. It can be used with a variety of languages (C++ and Python are the two big ones, though there is support for hooking into Java as well) and the licensing is sane.
Though I do favor wxWidgets (as it's all I really know) I believe QT is a lot more complete as a library. Depending on what you're doing, QT may be a better fit for your needs.
Be excellent to each other. And... PARTY ON, DUDES!
You really should be looking at JavaFX instead of Swing if you're interested in creating rich GUI environments in Java. You can get a good sense of the future of each of these technologies on Amy Fowler's blog. Amy was one of the founding members of the Swing toolkit - she knows what she's talking about. It's not always what Swing developers want to hear, but you know, life goes on.
Or ncurses. Or maybe flat HTML. Most sophisticated interfaces can be done with a bit of thought and caution in flat-text compatible formats that work very well with even the most modest text screens or flat text browsers. This makes them more robust, takes far fewer client resources, makes them more stable, makes them more portable, and avoids sophisticated GUI's with options and features that serve only to gratify the designer's wish to prove their sophistication, rather than actually get any work done. It also makes the tools accessible to visually impaired people, who may have trouble distinguishing sophisticated borders and popups that only work with certain browsers in certain modes. Fancy popups are often illegible to tired staff, and contribute to RSI.
A few years ago, I went through this this with a very expensive, very powerful system configuration tool absorbed thousands of hours in in-house engineering time trying to stabilize it and get it to actually follow our workflow, and was eventually thrown out in favor of Webmin. That project had wonderful plans, and resource allocations, and milestones, and Powerpoint slides, and managerial sponsors, and everything. But it _never worked_.
Use GUI's when you have to. Keep them simple, use well established tools, but don't design your own just because you can. Small changes to an existing tool that is similar will be a lot more stable than starting from scratch, and you can often get your changes implemented upstream to expand the existing tools as needed.
Agree with this. I have built a web site that allows drawing using the HTML5 canvas and it works fine. You would need to store persistent data somewhere but the
drawing is very easy and you can generate a PNG file from the canvas trivially.
This works with Firefox, Chrome and Opera on Windows and Linux. It won't work with IE7 and earlier (I haven't tried IE8 but I doubt it). It should work with Safari but I haven't tried it.
If interested, I can post links to good tutorials (but any reputable search engine should find them).
Ian McDowall
I'd suggest Processing. It's great for putting apps together quickly, has all the basic 2D tools you'll need, plus support for fancy-pants 3D stuff if you want it later. Great community and docs, too. Works on Windows, Linux and Mac.
http://www.processing.org/
I vote against using Qt. Having used and hacked it extensively (up to 4.8, or the master branch in git), Qt is way overboard for any simple project.
1 QtCreator is good as a common-platform IDE vs Eclipse, but cannot be used as a selling point for programming IN Qt
2 the code ISN'T as cross-platform as many would like to lead you to think because most here only did some simple apps in it, not full-blow production and public releases
3 the framework is TOO comprehensive and doesn't have a modular substructure to rip out unnecessary bloat; the MFC class structure lends to that bloat
4 it is easy to learn, but requires wrapping your head around weird idiosyncrasies of core elements that are poorly explained in the documentation and require trolling through the immense amount of source
5 Qt's problem reporting system pretty much buries any bugs or fixes you contribute that they don't personally like
Expanding on #2 and #3: Qt is only truly portable between Linux/MacOSX/MSWindows. It really sucks on embedded/smallMemoryCpu as they stopped supporting their qconfig modularization since 4.5. Ex. For Windows Mobile and other embedded, the smallest footprint is 12MB MINIMUM (Core, Gui, OGLES). That's > 50% of the entirely virtual memory available to a single WM app -- for a hello-world in OGLES.
Qt uses a strict single-tree (MFC) inheritance class hierarchy (instead of recursive templating due to legacy and hard-noses) which means code for everything ends up in the shared library, used or not. It's software rasterization most of the time and then hardware-accelerates the results, so it's not a true opengl renderer. You'll have to rewrite it yourself to clean it up. This means it has some speed but a lot of bloat in code and texture memory.
Their MOC is a nice alternative to ObjC, but it's a flawed design decision that didn't bet on the templating abilities of C++ modernization. Boost and Boost signals2 is a less magical alternative to Qt's signaling system.
If it was truly portable on mobile, why is it used extensively ONLY on Nokia products? There's few to zero examples for Symbian and Windows Mobile, and it's not ported to Android/iOS. This means you're already limited if you invest in Qt.
Their QGraphicsView canvas drawing layer is still immature and is still NOT multi-thread compatible (as much of Qt). This means you have to work your way around it a lot of times, or avoid it completely (and still can't compile out the software renderer) especially if you wanted a fancy multi-threaded renderer, or simply just loading textures in one thread and then drawing it in a master draw thread.
I strongly recommend going with a lighter, less drama foundation such as Clutter (which is MORE portable than Qt), SDL, or the bindings some languages provide such as gtk.