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."
HTML and Javascript?
Have you checked out vpython? not many people have heard of it and I find it quite usable.
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.
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.
Nothing is easier for amateurs, even though I'm no Microsoft fan.
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.)
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.
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.
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!
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.
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 :/
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.
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.
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.
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.
I haven't got a clue what kind of app you want to write, but have a look at Processing.org .
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.
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.
Adobe Air -
Easy UI interaction framework, very powerful drawing APIs, runs on windows/linux/mac/android.
http://www.adobe.com/products/air/
Latest version lets you call native apps on windows/linux/mac.
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.
Just another "Cubible(sic) Joe" 2 17 3061
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.
(For those that missed the reference, this is it)
"I'm never quite so stupid as when I'm being smart" (Linus van Pelt)
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 recommended it for general application writing just yet, but the original question was not very specific on the requirements so it might be suitable already in its current form.
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.
Be excellent to each other. And... PARTY ON, DUDES!
Nicely abstracted UIs and awesome user experiences are two orthogonal concepts.
I'll create a GUI interface using Visual Basic, to see if I can give you some mod points.
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.
I'd suggest Processing. It's great for putting apps together quickly, has all the basic 2D tools you'll need, plus support for fancy-pants 3D stuff if you want it later. Great community and docs, too. Works on Windows, Linux and Mac.
http://www.processing.org/
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 perl with apache on top -- and let some poor sucker straight out of college do the gee-wiz gui dance.
This way you get your own work done, and can create a solid platform for whatever craptastic client interface they come up with -- and the data can still be maintained, the QA on the actual backend algorithms can be implemented, and at least *you* have accomplished something on time and under budget.
Let the kiddies who made the mistake of getting into GUI at all fight their own way out of it.
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.
#include
Nuff said.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Except that JavaFX is less powerful than Swing. They're meant for different purposes.
One (JavaFX) is simplified and really intended for the web and web developers who can get away with less complex interfaces (since the expectations for interactivity on the web are so low compared with expectations on the desktop). The default set of controls for JavaFX have even more omissions than the default set for Swing (which both SwingLabs and the marketplace make up for fortunately).
On the other hand Swing is comprehensive and powerful. It is too much for many, but if you know how to wrangle it there is no substitute. If you want to *deeply* customize your controls you have the power to do so (many frameworks, eg SWT, WinForms etc have nice defaults, but once you start trying to extend them it gets very painful - moreso than Swing in my experience). I understand many hate Swing because of it's complexity or it doesn't work exactly as the Win32/WPF APIs do, but for me personally it is brilliant for multi-platform work and not yet found anything else that can touch it for sheer flexibility and customization.
So, while JavaFX is an option I don't think it is a generic solution to all classes of GUI problems (if you are going to invest time, effort and money you might as well use a 'swiss-army' toolkit that can apply to many problems).