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