Slashdot Mirror

← Back to Stories (view on slashdot.org)

What 2D GUI Foundation Do You Use?

Posted by Soulskill on from the maybe-it's-maybelline dept.

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

7 of 331 comments (clear)

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

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

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

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

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

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