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