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."
You haven't provided nearly enough information. Are you talking GUI interfaces, or rendering? If rendering, is it raster or vector? If vector, then what primitives do you need? Full SVG? Is this real-time, and if so, how many polygons / pixels do you need to push and at what minimum framerate?
As a totally shoot-from-the-hip, off-the-wall recommendation, I'd say OpenGL for portability, including support on iPhone / iPad / iPod touch. Note that you'll want to stick to the OpenGL ES subset in that case.
Better known as 318230.
I'd use Java AWT or OpenGL. They're both cross-platform, and what you learn will can be easily leveraged elsewhere, since they're widely adopted technologies. (No matter what you pick, you're going to have some learning curve.)
Having used everything on the list and much more (such as wx, GTK, etc), as well as making my own toolkits for embedded devices and products, my personal experience tells me hands down that Qt is the best choice for anything GUI related. It's power, ease of use, tools, documentation and learning curve are unparalleled to this day and age. Any other toolkit or API I've use fails in one or more of such areas.
Qt is the only toolkit that made me feel as if they could know in advance everything i'd ever need (so when i go to the docs it's there, right how as i imagined it should be), yet keeping the bloat down with great modularization. I have used it from C++ as well as from Python with great success.
I use the Qt framework at home and at work and I have published a couple teeny GPL'd apps:
Regardless of which framework you decide to use, I wish you luck!
OpenGL? "Lightweight"? Sure, I suppose because it's all implemented in the system, you don't have to redistribute much, but have you actually ever written anything remotely complicated in raw OpenGL? For anything resembling a GUI, the poster is going to spend months of writing low-level code that's been done a thousand times already.
Qt is heavy, but it's heavy for a reason - it includes a very nice set of tried-and-true widgets, with all the nice features and weird corner cases thought of already. It's also fairly speedy, and even more so if you use QGraphicsView, which can be optionally accelerated via OpenGL for even more speed.
Qt also has nice support for custom widgets. You can subclass any widget, or QWidget, and make anything you want. You can even integrate your custom widgets with Qt Designer, either by promoting a placeholder widget, or writing a Designer plugin so your widget is WYSIWYG.
OpenGL is so low level that everything I talked in the last two paragraphs is completely beyond its scope. Even font rendering is rather arduous, and good luck with nicely word-wrapped, formatted text.
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.
I'll create a GUI interface using Visual Basic, see if I can track 2D canvas objects.
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/
GTK+ is certainly weaker on the Windows and Mac side than Qt. But as far as speed and ease of coding, GTK+ is right up there. GTK++ is a great binding for C++, and PyGTK is quite good too. Writing Qt GUIs in PyQT is okay, but it's essentially the same as writing C++ code. In fact, it is the bindings where Qt is the weakest and where GTK+ is a bit better. Qt is written in C++ using the C++ object model and all it's features and warts. This does not always translate very well to other languages. A few years ago all Qt bindings for other languages were based on the QtC bindings because of this. Now Qt bindings are better. But GTK+, being based on a much simpler object model (the GOject) is very easy to wrap in C++, Perl, Python, Ruby, etc. PyGTK is one of the more comfortable toolkits to develop in and feels more at home in Python than Qt (PyQT; never have used pyside).
GTK+ is hardly the "grave danger" the parent claims. For a lot of things it is a very nice toolkit to develop in. And the parent's statements on Tk are are not quite accurate. Tk is still alive and well, and looks reasonable in the modern incarnations on the big 3 platforms. It seems a bit daft to me to embed another entire language in my program (tcl) but sometimes that just might be the easiest. Many little utilities written in Python still use Tk. It's fast, easy, and always there if Python is there.