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

13 of 331 comments (clear)

  1. More information by Dan+East · · Score: 5, Insightful

    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.
  2. AWT or OpenGL by Philotomy · · Score: 5, Informative

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

  3. Qt by goruka · · Score: 5, Informative

    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.

    1. Re:Qt by Anonymous Coward · · Score: 5, Interesting

      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? :)

    2. Re:Qt by simula · · Score: 5, Informative

      What do you want from the commercial license that you aren't getting with the LGPL version?

      The LGPL license allows you to close your product and distribute it without opening your source code as long as you link to the Qt dynamic libraries.

      If you make changes to Qt itself, you are required to open those changes back up, but as long as you utilize dynamic libraries, you can make your app as closed as you want.

    3. Re:Qt by ByteSlicer · · Score: 5, Informative
      Dynamic linking is certainly possible with the QT libraries.
      Just because your C++ applications contains some function signatures, symbols and constants from the QT API doesn't make it a 'real' derived work, since this is using the library as intended.
      One part of LGPL section 5 states this:

      If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work.

      On the GNU website you can find the official standpoint on this matter.

  4. Qt by simula · · Score: 5, Informative
    If you are comfortable with C++, I heavily recommend the Qt framework.
    • There is an LGPL ide Qt-Creator that has an integrated form designer.
    • The code you write is amazingly cross-platform.
    • The framework is amazingly comprehensive for when your needs expand.
    • There are top notch learning resources, including excellent books.
    • The Qt framework is LGPL.

    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!

  5. Re:Obvious choice is OpenGL by TD-Linux · · Score: 5, Informative

    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.

  6. I second this, OpenGL and QT are both great. by joetainment · · Score: 5, Interesting

    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.

  7. Re:The answer by Anonymous Coward · · Score: 5, Funny

    I'll create a GUI interface using Visual Basic, see if I can track 2D canvas objects.

  8. JAVA + SWING by tgetzoya · · Score: 5, Interesting

    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.

  9. Re:HTML and Javascript? by arivanov · · Score: 5, Interesting

    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/
  10. Re:HTML and Javascript? by caseih · · Score: 5, Informative

    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.