Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
GUI Graphics

What 2D GUI Foundation Do You Use? 331

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."
This discussion has been archived. No new comments can be posted.

What 2D GUI Foundation Do You Use?

Comments Filter:
  • HTML and Javascript? (Score:4, Informative)

    by Anonymous Coward on Sunday November 28, 2010 @12:15AM (#34362282)

    HTML and Javascript?

    • Re: (Score:2, Interesting)

      QT and PySide for doing GUI with Python.

      QT for C++
      • by arivanov ( 12034 ) on Sunday November 28, 2010 @04:07AM (#34363066) Homepage

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

        • by caseih ( 160668 ) on Sunday November 28, 2010 @03:43PM (#34366848)

          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.

          • by arivanov ( 12034 )

            But as far as speed and ease of coding, GTK+ is right up there.

            As I said:

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

            The general problem with GTK is that if you follow the "easy" way you end up with an app whose UI is embedded into its state diagram. You cannot after that (at least without considerable effort) disentangle this UI from the backend and isolate portions of the backend to run headless. As a result making your app make use of a modern multicore machine is outright painful. It is not impossible, but hurts none the less. You are also much more likely to end up sitting on locks in many places which nega

            • Re: (Score:3, Insightful)

              by digitalunity ( 19107 )

              That's a good point here in that Qt isn't just a GUI. It's a complete application framework, including threading, super easy mutexes, thread pool automation, multimedia, scripting, etc.

              The GUI is only a small part of the Qt library.

    • by g4b ( 956118 ) on Sunday November 28, 2010 @09:52AM (#34364144) Homepage

      You could use Googles GWT to write your GUI, and simply display a webkit window in the application, making it server-client friendly and usable via browser if needed.

      GWT is fairly cool and very advanced. You write stuff in Java, and it is translated to browser specific javascripts.

      However, I would still use Qt. For smaller projects I used wx already. PITA.

  • Anonymous Coward (Score:2, Informative)

    by Anonymous Coward

    Have you checked out vpython? not many people have heard of it and I find it quite usable.

  • by Anonymous Coward

    OpenGL is portable across all platforms, hardware accelerated, and lightweight. Win, win, win.

    Qt would be my next choice but it's not lightweight at all. You can always wrap your OpenGL app with Qt for extra "GUI stuff" if needed. OpenGL works with practically everything.

    • Yeah but it's a royal pain to write anything nontrivial in straight OpenGL.
    • by TD-Linux ( 1295697 ) on Sunday November 28, 2010 @12:52AM (#34362436)
      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.
      • Re: (Score:2, Informative)

        by coaxial ( 28297 )

        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.

        Wha? GLUT [] and GLUI [] don't exist? Sure they're ugly as hell, but that's a different story.

    • by joetainment ( 891917 ) on Sunday November 28, 2010 @12:54AM (#34362452)

      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.

      • Thanks to you for the tip on pyside. I was looking around at this stuff and didn't know where to start.

        This really IS pretty cool.

      • Qt has recently introduced Qt Quick [], a collection of technologies meant to help you create animation-rich UIs similar to those used on touch phones. The most important part is the QML language [], which is used to describe the user interface of a program. QML is declarative and animation-friendly, and makes it easy to create fluid interfaces. On the downside, it is not mature yet and lacks most of the standard UI widgets at the moment (basically, you have text input and clickable areas). I wouldn't have recomm
      • Re: (Score:3, Informative)

        Good post, just wanted to add that there are bindings for Java available, see here []
      • Re: (Score:3, Informative)

        About the only downside is that there aren't current C# or Java bindings for it.

        Umm... Qtjambi [] (QT's Java bindings) has been available for ages, although recently Nokia transferred the ownership to community, but from the looks of it, the community is very active and the releases are on track.

  • by CosmeticLobotamy ( 155360 ) on Sunday November 28, 2010 @12:19AM (#34362306)

    GDI+ is good enough for low frame rates and trivial to use if you have any C# experience. If these are static controls that need to be painted and then updated on user input, it's more than sufficient.

  • .NET Windows Forms (Score:4, Informative)

    by peterindistantland ( 1487953 ) on Sunday November 28, 2010 @12:21AM (#34362318)
    Nothing is easier for amateurs, even though I'm no Microsoft fan.
    • Seconded. Windows Forms is easy to learn, powerful enough to use for most GUI work, and if you stick to the classes that work in Mono, it's cross-platform with little if any changes required.

  • Design your application to modularize the OS-dependent code away from the OS-independent code. When it comes time to port (if it ever happens) you should only have to worry about the OS-dependent stuff with minimal modification to the core of the application.

    • by abdulla ( 523920 )
      The real problem with that is some of the platform dependencies won't be clearly visible until you've ported the code to other platforms. You may have designed something that works very well with one platform, but is insupportable on another. I believe there is something akin to "the rule of 3", where you only know if something is truly portable if you have successfully ported it to at least 3 different platforms.
    • Re: (Score:3, Insightful)

      by TD-Linux ( 1295697 )
      While this can be a great thing, if you do this for the sake of separation, you'll do it wrong.
      When separating your OS-dependent code, many people make a nice wrapper library for the various toolkits. This is a great way to reinvent the wheel yet again.
      However, if you program is oriented around the GUI (a file manager, IRC client, etc), there is no good reason to separate GUI... you'll just end up with a poorly documented GUI abstraction layer. You'd be better off using any other portable GUI toolkit.
      • by putaro ( 235078 )

        If you make a general purpose wrapper layer, yes, you'll end up with a mess. A different way to do is to decompose your GUI along MVC (Model View Controller) lines and make different View layers for the different OS's/toolkits. Rather than making a general purpose wrapper you have a single purpose wrapper. I've done this and it works quite well.

  • More information (Score:5, Insightful)

    by Dan East ( 318230 ) on Sunday November 28, 2010 @12:27AM (#34362338) Journal

    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.

    • Re: (Score:3, Informative)

      by Zmee ( 806851 )

      Original poster here. I am looking to implement a customized card game (think Magic [] or Yu-Gi-Oh []). This is my step-son's first foray into development, and my first UI requiring any custom controls. (I have done a fair bit of ASP.NET, PHP, and Windows Forms, but most of that is not applicable given what I am planning here). The idea is to be able to create the card images from a combination of stored bitmaps, text, and some general backgrounds. As such, much of the GUI will be vectored, but some must be raste

  • AWT or OpenGL (Score:5, Informative)

    by Philotomy ( 1635267 ) on Sunday November 28, 2010 @12:30AM (#34362352)
    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.)
    • Re: (Score:3, Interesting)

      by timothyb89 ( 1259272 )
      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 lo
  • FLTK (Score:5, Interesting)

    by printman ( 54032 ) on Sunday November 28, 2010 @12:30AM (#34362356) Homepage

    FLTK ( 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.

    • Re:FLTK (Score:4, Interesting)

      by joss ( 1346 ) on Sunday November 28, 2010 @07:22AM (#34363520) Homepage

      I love FLTK, I really do, but .. I dunno, now PySide is around I might have to go over to Qt..just seems that fltk progress is a little glacial and pyFLTK has not been updated since 2009. C++ for everything seems a little painful these days

  • I would recommend OpenGL because its flexible, efficient, and cross platform. DirectX is a lot easier to use for 3D graphics but for simple 2D stuff I wouldn't mind using OpenGL and it's worth it for the benefit of being cross platform.

  • WPF, Qt, or Python (Score:4, Informative)

    by PhrostyMcByte ( 589271 ) <> on Sunday November 28, 2010 @12:37AM (#34362388) Homepage

    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.

    • by forkazoo ( 138186 ) <> on Sunday November 28, 2010 @01:29AM (#34362634) Homepage

      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.

    • Re: (Score:3, Interesting)

      I also avoid GTK, but mainly just because it always feels "off" on Windows.

      I have heard good things about the FOX toolkit ( []). The Goggles Music Manager was written using this. Looks very Windows-ish on Linux, so I would expect it to FOX based apps to be comfortable for Windows users.

    • I also avoid GTK, but mainly just because it always feels "off" on Windows.

      Understatement of the year.

      I wouldn't say "feels 'off'", more like "is implemented completely backwards and upside-down and nothing fucking works right, not even something braindead-simple like Open dialogs."

  • Qt (Score:5, Informative)

    by goruka ( 1721094 ) on Sunday November 28, 2010 @12:37AM (#34362392)
    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.
    • Re:Qt (Score:5, Interesting)

      by Anonymous Coward on Sunday November 28, 2010 @12:47AM (#34362422)

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

    • Re:Qt (Score:4, Interesting)

      by Twinbee ( 767046 ) on Sunday November 28, 2010 @12:54AM (#34362450) Homepage
      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: []

      I'm hoping Nokia will adjust their stance on this issue, otherwise .NET/Winforms/WPF looks ever more tempting.
      • Re:Qt (Score:5, Informative)

        by simula ( 1032230 ) on Sunday November 28, 2010 @01:21AM (#34362604) Homepage
        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.
        • Re: (Score:3, Interesting)

          by QuantumG ( 50515 ) *

          I love the way people say this stuff about the LGPL.. have you ever actually read it []? This is the bit you're probably referring to:

          6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.

          The newer version 3 [] of the license has more clear wording, which are actually more restrictive.. permitting modification of only the library not the combined work.

          In either case, every time you say "you can link to LGPL licensed libraries without having to do anything!!" you're inviting people to violate the author of that library's license.. I'm sure they appreciate it.

          • Re: (Score:3, Informative)

            by Anonymous Coward

            Please don't mod this informative, the GP's interpretation is correct.


      • To be fair, I'm not sure how strictly that provision is actually enforced. If you actually show up with a pile of cash and try to sweet talk your salesman, I'm pretty sure he'll do just about anything to take some of your cash. Besides, there are relatively few cases where you would really need something other than LGPL. Under LGPL, you can charge for your software, keep your application source closed, and even make extensive changes to Qt itself. The only thing you would need to do is make changes to Q

      • by Kjella ( 173770 )

        This was a lot more true when Qt was GPL, but being LGPL you can write and sell closed source applications with it as long as you contribute back any improvements you make to the library. Other people will not be able to give away copies of your software because the GPL only gives them distribution rights to the library, not the whole thing as with the GPL. Very few projects should need the commercial license anymore, and if you do because of some anal platform requirements like iOS or consoles then Qt does

  • by TexVex ( 669445 )
    I'm personally a fan of .NET, mainly because the toolset goes a long way towards making development easy. Consider: You start the Visual Studio C# IDE, create a new Windows Forms application, then use a simple menu selection to create a new User Control class. You are given a canvas and can immediately begin adding existing controls to it, and if you want to custom-draw the whole thing then you just use the Events tab of the Properties window to create a handler for the Paint event. The paint event handler'
    • by wasabii ( 693236 )

      ".Net" isn't a UI platform. You probably mean WinForms. Or maybe WPF. There are other UI frameworks for .Net, I used to do a lot of work in Gtk#, before I switched to WPF.

      I've never used WInforms for anything serious though. Gtk# was always better than it, back then.

  • Qt (Score:5, Informative)

    by simula ( 1032230 ) on Sunday November 28, 2010 @12:39AM (#34362396) Homepage
    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!

    • Re: (Score:3, Interesting)

      by TD-Linux ( 1295697 )
      As much as the parent comment looks like an ad, I've used Qt and can say that my experience matches what the parent said.

      I use Qt Creator as my IDE and it's great with the Designer integration. It's not quite as full-featured in some respects to Visual Studio or KDevelop (Qt works with VS as well), but the integration with the documentation and preprocessor makes up for it.

      And the key is of course the documentation. Qt's documentation is possibly the best example of what a doxygen-based documentation
    • Qt has flaws (Score:4, Informative)

      by valkenar ( 307241 ) <> on Sunday November 28, 2010 @01:18AM (#34362588) Journal

      I use QT and love it too, but it has some serious drawbacks, from my perspective. The biggest is that it requires a wonky special compilation system. You either have to use the build system they offer (qmake) or you have to manually run their generator yourself (moc - though if you were a masochist you could learn to write out the files moc makes yourself and avoid using it).

      I compare every IDE to Eclipse, because that's the best IDE I've seen for any language. But I've never found that CDT, the C++ plugin for Eclipse, is any good. It fails to work out of the box for me and is a pain to configure (but I haven't tried it in a few years). QT Creator, while usable, is really an immature product. There's no support for refactoring, the UI is unintuitive and awkward (for me, at least) and there's lots of little issues with it. Plus you're committed to MingW, which can be a problem depending on what libraries you want to use. Codeblocks is a pretty good IDE, but it doesn't have a QT plugin, so you're left with the problem of dealing with moc files. Visual Studio has a plugin, but it only works with the paid versions.

      All of this can be dealt with (and I do) but it's annoying.

      • Re:Qt has flaws (Score:4, Informative)

        by TD-Linux ( 1295697 ) on Sunday November 28, 2010 @01:30AM (#34362646)
        The "wonky" compilation system isn't bad, and the benefits it provides overcome any ideological "oh my we are corrupting the pure and wonderful C++" feelings that I might have. It's really easy to integrate into CMake, and it doesn't matter with autotools, because everything is hard with autotools.

        I also don't know where you got the idea that the VS plugin works only with paid versions. It works fine with the LGPL plugin for me.
        • Re: (Score:2, Informative)

          by wssddc ( 450574 )

          I also don't know where you got the idea that the VS plugin works only with paid versions. It works fine with the LGPL plugin for me.

          It's a paid version of Visual Studio that is needed. The plugin refuses to install if you only have the free VS Express.

    • by NuShrike ( 561140 ) on Sunday November 28, 2010 @02:27PM (#34366050)

      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.

  • WPF (Score:3, Interesting)

    by gadzook33 ( 740455 ) on Sunday November 28, 2010 @12:41AM (#34362398)
    I have extensive experience using Qt under both linux and windows (5+ years), as well as WinForms. However, for the last year I've been using WPF and I think it's a dream. Granted, there are cons to it and if your bottom line is performance in all situations (e.g. this is a game) then I would avoid it. They talk a big game about high object counts, but it requires extensive virtualization and time and then it still might not work depending on what you're trying to do. That being said, WPF's use of binding is fantastic and if you do a little bit of homework on binding I think you'll be pleasantly surprised. Don't get me wrong, I love Qt (and C++ for that matter!). But for the amount of stuff I need to crank out, it's tough to beat WPF. One last caveat: I wouldn't count on Mono to bring your apps to linux. I've only spent a little time with mono, but unfortunately (in my opinion), the linux community seems to have largely shunned C#, .NET and all that goes with it.
    • by wasabii ( 693236 )

      I agree. WPF's design is quite unlike any other UI toolkit I'm aware of. I wish there was a version that worked on !Windows.

      • Re: (Score:3, Interesting)

        by wasabii ( 693236 )

        The whole 'recursively templated tree' thing is really ingenious. It sets it quite a bit apart from the single tree model of all the other frameworks I'm aware of.

  • I was about to reply some pros&cons and that in the end all frameworks have their limits and how if you try something else than asking for a birthdate in a textbox and outputing the age in another when the user hits a button you'll spend hours and hours tweaking little details (why won't it let me put an icon here! Why won't it align correctly!)

    But I re-read you question and you talk about re-writing all the GUI yourself, so I don't really understand why you need a UI toolkit to start with. But you pr

  • More info needed (Score:3, Insightful)

    by BitZtream ( 692029 ) on Sunday November 28, 2010 @12:52AM (#34362438)

    If you want 'easy' with a slightly 'limited' set of options long term, then I would say Windows Forms in a .NET language, use Mono rather than VisualStudio so you have a much easier chance of it working in Linux out of the box, and most likely OSX, FreeBSD and several others in the process. Its not required, but Mono's code completion will point you in the right direction where as VisualStudio is going to point you more towards MSy things. Though VisualStudio is much more enjoyable to use in my opinion. If you've never used either, its not likely to matter for a while I suspect, though on OS X, Mono seems to miss most initial clicks I send to it, could just be me.

    That will give you all the basic controls an application gui will need and make it so you can reuse the massive amount of examples out there.

    For your custom painted widget its a little different. What kind of painting are you doing?

    Is it something that lends itself to OpenGL really well? If its fits well into geometric primatives, then I would go with OpenTK's OpenGL Control. Works pretty good in my experience.

    How often does it update the displayed data? Is it a game/animation kind of thing or are we talking about something that renders once after the user changes a setting?

    If you need a high FPS on the updates, you're going to want to use OpenGL with textures for displaying the rasterized data. You're learning curve will be a little steep I think if you're starting from no knowledge, but its probably your only solution for something that needs to be fast (I'm just flat out ignoring DirectX, which for Windows would be easier than OGL but would cut you off of Linux and the advantages on Windows aren't that great really)

    If you have real slow update rates, then you could just throw a image control on a form and paint the pixels yourself one at a time, or load images from a file/resource.

    If this is a project that has a long expected life and will become rather complex and need high performance eventually, then you're probably going to do it wrong the first time no matter WHAT you do now, at least, thats my experience. I never get it right until AT LEAST the 3rd rewrite :/

  • by spitzak ( 4019 ) on Sunday November 28, 2010 @12:52AM (#34362440) Homepage

    Stop suggesting various toolkits, that is NOT what he is looking for.

    He is looking for a "canvas" widget, meaning he wants drawing API.

    It is unfortunate that most drawing apis are tied to particular toolkits, so he may have to choose one, but if you are comparing them you have to compare the 2D drawing primitives.

    There is also Cairo and OpenGL, which are not really tied to toolkits. Though you still need to jump through hoops depending on the toolkit to get it so the graphics calls draw where you want. Sigh.

    • Actually, we have no idea what he's looking for (and I don't think he does either). "Paint custom objects"? That could mean just about anything.

    • by tibit ( 1762298 )

      A canvas, to be useful, needs a whole lot of supporting code. If you go the whole nine yards, you end up with an application development toolkit like Qt. Suppose you have some text that needs editing on the canvas. Do you really want to implement text editing GUI yourself? While this may be simple for a fixed width font, things get tricky with kerning and multiple formattings, and you start getting sidetracked a lot when your right-to-left locale customers complain that nothing works.

      Qt's QGraphicsView [] is t

  • I am looking to build a 2D application for personal use and I will need to use a canvas to paint custom objects.

    Not enough info, really, but I'm wondering if you've considered making this a web app; then it would be compatible with anything with a modern browser.

  • I've done a lot of programing but not a lot of UI work outside of the browser (where most of my user interaction has been). However, I've found that the JAVA SWT to be "okay" for desktop GUI apps. Sure, it isn't as flexible as opengl or javascript/html(xml)/css, but it gets the job done for your standard inputs and outputs. If you want to do something fancier than the most basic 2d graphics (or minecraft-like 3d) you won't like it and neither will your users.

    Mostly what you should ask yourself is "Can a bro

  • Been using OpenGL and FLTK for a project for a few weeks now. Hope I never have to use anything else.

  • As you have noted, it does take a commitment to learn any system. For personal projects where you answer to no one else, you should use whatever you think will be useful to know in the future. The factors involved are: what will be used for future projects at work, how important is cross platform programming, and what looks good on a resume.

    For cross platform work, Qt is the way to go. Or Java I suppose, but I have found myself moving away from that language. Not for any ideological reason, I've just had a

  • Swing + Java2D (Score:5, Informative)

    by SplashMyBandit ( 1543257 ) on Sunday November 28, 2010 @01:04AM (#34362512)

    Who suggested Java AWT? What is this, 1998? Someone is behind on their homework :).

    Java's Swing + Java2D is *fully hardware accelerated* (ever since Java 1.6.0_u10 some time ago), multi-platform, with good multi-thread support (not for rendering, you don't need that, but for the rest of the program), very customizable, and looks fantastic with the Nimbus look&feel (a standard part of Java). Swing is used a lot on the enterprise desktop (and a few shrink wrapped products too - I know I've purchased some as they were best-of-breed tools). Many of the Java Swing ttools are free and there are a lot of them (eg. Matisse in Netbeans makes creating GUIs a snap). Java2D had extensive contributions from Adobe who happen to know a thing or two about presentation. Plus, drawing in Java2D also allows printing relatively simply.

    • Re: (Score:2, Informative)

      by Philotomy ( 1635267 )
      Java2D is part of AWT (take a look at the Java2D API and its packages). Ultimately, Swing is built on top of AWT (yes, even the lightweight widgets). The OP was talking about drawing "custom objects" on a canvas, which sounds more like custom painting using Java2D rather than making use of widgets. For a widget-based UI, I think you're right on the money suggesting Swing. For painting custom objects, you're going to be using classes in the java.awt.* package.
      • Re: (Score:3, Interesting)

        Thanks. It might be in the AWT package but if he was limiting yourself to only AWT then I suggest he's not considering the possibilities that Swing adds above AWT. Colouring the pixels on the screen is only part of it, you also need buffering and layers (the handy GlassPane) etc to do cool stuff (drawing with some of the concepts of 'Filthy Rich Clients'). Hence, I mention Swing as good for drawing above and beyond the confines of AWT.

        What I forgot to mention is that you can mix OpenGL with a Swing canvas

  • Quick n dirty. (Score:2, Informative)

    by noodler ( 724788 )

    I haven't got a clue what kind of app you want to write, but have a look at .
    It's an abstraction layer built on top of Java (cross platformity, including web browsers).
    It has loads of handy stuff for 2D and 3D, including OpenGL.
    Talking about OpenGL, you can use it in it's raw form as well.
    In fact, you can just write in Java afaik.

    I found it very usefull for making custom ui's.

  • Having no clue what you're looking to do, a modern web-browser, or next-gen with graphics accelleration, may be sufficient. I wouldn't suggest it for anything too significant, but between SVG, and general web graphics stuff -- something like imagemagick or yoru favourite command-line image processor -- most interfaces are fairly easy, and a very low learning curve. Heck, in IE you can even transform them with a matrix operation. You'd be using javascript for animation and logic.

  • Easy Choice (Score:4, Informative)

    by fean ( 212516 ) on Sunday November 28, 2010 @01:22AM (#34362608) Homepage

    Adobe Air -
    Easy UI interaction framework, very powerful drawing APIs, runs on windows/linux/mac/android. []

    Latest version lets you call native apps on windows/linux/mac.

    • Re: (Score:3, Insightful)

      by Alex Zepeda ( 10955 )

      And also really, really bloated memory usage, widgets that don't act like native widgets, and the ability to make use of my laptop's nifty fan like no other. Seriously. Two hundred tabs in Firefox, and the laptop would remain quiet. Open up an AIR app and... it gets hot and the fan goes nuts. Take a look at most of the desktop Twitter clients as an example. TweetDeck is a good one because it highlights most of my issues. It runs on OS X, but not well. I was able to put up with using ~1gb RAM for a

  • For "personal" Apps (Score:5, Informative)

    by ratboy666 ( 104074 ) <fred_weigel AT hotmail DOT com> on Sunday November 28, 2010 @01:29AM (#34362636) Journal

    I don't have much time... I write the GUI, and any drawing logic with Tcl/Tk. Easy, portable. Any time critical or extensive logic gets pushed into C or FORTRAN (depending on what it is). Just standard in/standard out. Parse the output with Tcl, and display.

    A recent example -- I needed to upgrade some systems for a client (Solaris 6 to 10). We needed to identify the binary parts (non-OS) that needed to move. I wrote a GUI tool (binport) for this. Took 2 days to write, ran on Linux and MacOS X (two of us shared the work). After the job, the tool was essentially discarded.

    No time to "debug" really, and I don't typically have time for compile and test cycles. Tcl is an interpreter, with very simple syntax and semantics.

    Other examples that have used Tcl/Tk -- the GUI layer for GDB, Redhat Source Navigator, etc.

    Yes, it's not "sexy", or even particularly "new", but it works, and works well.

    • TCL does compile to byte code so interpreter is not entirely true - but that true of everything these days.

      The language itself is very easy to learn, with a clean and consistent syntax. It does unicode right, it has a fast regular expression engine, it has a reliable sub-interpreter system for sandboxing untrusted code, its entirely cross-platform and it is very easy to create executables for multiple platforms, it has a helpful community and very very useful wiki, its easy to embed, and a lot more.

      The disa

  • Java/AWT pro: tends to work on all platforms. con: your app generally tends to look bad on every platform.

    Java/SWT: pro: tends to work well on all platforms. con: you might have to drink the eclipse kool-aid

    Tcl/TK: It is a silly language. You don't want to go there.

    OpenGL pro: "gui" portion tends to work on all platforms w/tweaks. con: hard to work with unless you adopt some toolkit.

    In practice, however, if you really only care about Windows, write windows native code and allow WINE to take care
    of the

  • link []

    The EFL begins with Evas, our canvas library. Because Evas is built on several different selectable engines (Linux FrameBuffer, DirectFB, X11, OpenGL/OpenGL-ES, QTopia, etc) the platform is extremely portable, which translates thru to all of the libraries built on top of it.

    Hey, if they were good enough to run a Brazilian fridge [], they should be good enough for you. Seriously though, you should take at look at the EFL. They are flexible, powerful and efficient. There will be a learning curve with whatever libraries you choose to use. You might as well get something wonderful in return for your investment of time and energy. You want the efficiency of OpenGL without the limitations? You got it.

  • If the OP is looking for a Web-based GUI, then consider OpenLaszlo (

  • Tcl/Tk, Swing, and (for mathematics) the Matlab GUI served me well (even if the latter one is single-threaded and awkward, its a productive and stable environment).

  • You may as well. Toolkits are the bane of human interface design. Each one behaves differently.

  • Most portable? OpenGL. Has the benefit of not requiring huge libraries ala Qt. Consider sticking to OpenGL ES 2.0. Most useful? Quartz/CoreGraphics. Not a portable choice of course, but a good drawing toolkit none the less.
  • JAVA + SWING (Score:5, Interesting)

    by tgetzoya ( 827201 ) on Sunday November 28, 2010 @02:34AM (#34362876)
    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 use wxWidgets (Score:4, Interesting)

    by GeckoFood ( 585211 ) * <> on Sunday November 28, 2010 @08:06AM (#34363656) Journal

    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.

    • Re: (Score:3, Interesting)

      by g4b ( 956118 )

      I have done a kiosk like application for a bigger university in the past, which is based on wxPython entirely. It still runs on those machines until today and does its job very well. Its a rather big app.

      For most simple applications WX does suffice. However, I had to do of workarounds and finally ended up "abstracting" wx to our needs, mostly because some tests showed, you can crash wx in the background unfortunately in some circumstances. (just do a lot of sizers and tell him to apply them very fast)

      In my

  • Curses (Score:3, Interesting)

    by Antique Geekmeister ( 740220 ) on Sunday November 28, 2010 @11:38AM (#34364744)

    Or ncurses. Or maybe flat HTML. Most sophisticated interfaces can be done with a bit of thought and caution in flat-text compatible formats that work very well with even the most modest text screens or flat text browsers. This makes them more robust, takes far fewer client resources, makes them more stable, makes them more portable, and avoids sophisticated GUI's with options and features that serve only to gratify the designer's wish to prove their sophistication, rather than actually get any work done. It also makes the tools accessible to visually impaired people, who may have trouble distinguishing sophisticated borders and popups that only work with certain browsers in certain modes. Fancy popups are often illegible to tired staff, and contribute to RSI.

    A few years ago, I went through this this with a very expensive, very powerful system configuration tool absorbed thousands of hours in in-house engineering time trying to stabilize it and get it to actually follow our workflow, and was eventually thrown out in favor of Webmin. That project had wonderful plans, and resource allocations, and milestones, and Powerpoint slides, and managerial sponsors, and everything. But it _never worked_.

    Use GUI's when you have to. Keep them simple, use well established tools, but don't design your own just because you can. Small changes to an existing tool that is similar will be a lot more stable than starting from scratch, and you can often get your changes implemented upstream to expand the existing tools as needed.

    • Re:Curses AMEN! (Score:3, Insightful)

      by wagadog ( 545179 )

      I've never seen a gui project that didn't get bogged down in the problem of the PMs and everybody down to the second owner's third wife wanting to repaint the bike shed a different color, and change the workflow at the same time, while all the time confounding the issues they create even further by not knowing the difference between the two.

      If the problem is actually somewhat complicated, implement each action as a straight-to-the-shell command line interfaces, invoke them on the server side via python or p

  • by SpaghettiPattern ( 609814 ) on Sunday November 28, 2010 @06:21PM (#34368506)

    Nuff said.

Friction is a drag.