Thursday, March 1, 2007

I need a GUI for my application. What library should I chose?

Hi there. I recently had an idea about a nice desktop application that I would like to write. I know a handful of programming languages, but none is very good for what I want. Let me tell you what it is about and please disagree with me.

The application I want. I'm taking a course on Embedded Systems this semester. I'm a CS student, so I don't know much (read: know next to nothing) about hardware design. But I learned about logical gates, and latches, and stuff like that, and I have a pretty good idea about how one would go about building a small processor.

I would like to be able to play with these small hardware components, and I intend to write a small simulator for myself. The basic nonfunctional requirements of the simulator are the following:

  • graphical user interface. Although I understand the superiority of a text oriented hardware description language + parser, I feel that a GUI would allow me to get a better feeling for hardware
  • cross platform

Of course, I have a good idea about how one would go in writing such a program. Except that I can't decide on a programming language/platform for the project because of the lack of good GUIs. Here are my current thoughts on this matter:

  • Java. As far as I'm concerned, even though I hate Java-the-language very much, this is my best choice so far. Java has a decent cross-platform GUI, is reasonably efficient, and I can get around the language for some of the more advanced things I want. However, thinking about the huge amount of code it would take to do even the most basic processing makes me take a step back.
  • C#. I find C# to be better language than Java, but it has a huge problem: it's not cross platform (yes, I do know about Mono).
  • C++. Ah. This is the language that I am most experienced with. Even though it doesn't do garbage collection and doesn't manage the code for me, C++ is somewhat better than Java from a language semantics point of view. However, it lacks a standard GUI. Let's look at the GUI libraries you can find:
    • QT. No thanks. I don't like metacompilers. Compiling C++ code is already very slow; I don't want the metacompiler to take another age. I don't like proprietary. I don't like the license. The GUI code, however, is quite clean and workable with.
    • MFC. NOT. The code is messy, proprietary and not cross-platform.
    • GTK+. The syntax is somewhat better and wxWidgets, but it's still messy. Also, it's not really C++. I don't like reading GTK code. I do like the box feature though. Documentation is not as good as it should be.
    • GTKMM. Better than GTK+ because it's more C++. However, the syntax is still not as good as it should be and it's not as flexible as wxWidgets. The documentation needs more work. If I would chose C++ for this project, GTKMM would probably be my GUI library.
    • wxWidgets. Well, this one is, imho, the best GUI for C++ ever. However, it's just as messy as MFC, and I don't like the code at all. Quite good documentation.
You see, C++ libraries are huge mess. It's very difficult to chose one, and, once you do, you're pretty much stuck with it. Are you sure? [Y,n]
  • Python is one of my favorite languages. It is very easy to write good Python code and you can find a library with good docs for just about anything. However, Python is lacking at the speed chapter. You see, Python can be up to 50 times slower than C++. That can be the difference between waiting one second for a simulation to finish, and waiting 1 minute. Python comes with standard Tk bindings, but I would probably chose it's wxWidgets bindings for extra power.
  • Haskell. Haskell is another favorite of mine when it comes to coding algorithms. Haskell comes lazily evaluated by default, but I'm not very concerned about it's speed limitations. What I am concerned about is that there is no standard GUI library and there are no good bindings to other libraries -- all of them wrap code around the IO monad, making it bad on your eyes.
  • Ocaml is Haskell's older cousin. Ocaml doesn't come lazily evaluated and is dead fast. It is very expressive when it comes to coding algorithms, but the GUI bindings are really bad from an aesthetic point of view.
  • Lisp/Scheme. Which one? I'm sure they are fast enough for what I need, and I'm sure that the code will end up to be very elegant, but I don't have any experience with GUIs for either of the two. Can anyone share some insight into this?

Although I would like to have all the source code in just one language, I'll probably end up choosing one language for the GUI and another for the backend. Currently I'm thinking about choosing Java or Python for the GUI and C++ or Haskell for the backend. Of course, interop will be very fun and I'll probably end up duplicating code between the two languages.

Have fun and may you never need to think about this kind of shit.

23 comments:

CISCBrain said...

Why are you disqualifying Mono right from the start? :)

How about F#? It's a nice language, it's cross platform (AFAIK F# binaries run on Mono) and you can use either GTK# or wxWidgets for the GUI.

>Have fun and may you never need to think about this kind of shit.
Hehe... thinking about this kind of shit makes you a better programmer.

stefan.ciobaca said...

Imo, Mono is not quite ready for prime time yet. It's the kind of thing that you will use happily right until there's an unimplemented feature that you really need and you don't really want/have time to implement it yourself. Then, you're pretty much on your own... (remember how in the days of .net 1.0 you had to use Win32 Api for just about anything interesting in a GUI because WinForms sucked?)
F# is just Ocaml syntax on top of .Net. It's a very interesting concept, and I definitely understand why Microsoft wants to promote it. However, it still suffers from Ocaml's syntax problem when it comes to building GUIs.

Anonymous said...

What about wxWidgets (www.wxwidgets.org)? Its open source, supported on Windows, Linux, OS X, etc. It also has a Python binding (wxPython), and probably bindings for other languages

stefan.ciobaca said...

People doing real-world cross platform development should definitely consider wxWidgets, but I think the C++ syntax is plain ugly.
The Python version is ok.

Anonymous said...

I don't understand your "performance" concern. You're not developping a 3D FPS, you are developping a desktop app. Your programming ability will be a bottleneck faaar before the overhead due to language interpretation/level of abstraction/size of the api. Moreover, you are dismissing a lot of options based on pre-conceptions, and not on actual facts and your experience.

Anonymous said...

Python *can* be a lot slower than fast C++ code. But, that's rarely the case. I'd suggest going with Python: the wxPython library is really nice. If it's too slow, then profile the code and fix the slow parts. If it's still too slow, then worry about the speed. But that probably won't happen.

Anonymous said...

Take the java route. You don't need to write java code to take advantage of the jvm and swing.
There are lots of alternatives:
scala, jruby, jython, groovy, javascript(Rhino) .... just look for the language you.

Bill Mill said...

Agreed with a couple other posters - write it in Python/wx, profile, use psyco, then drop down into c/c++ if necessary.

Anonymous said...

like..

always to early on the publish button...
see
this
for an overview of languages supported by the jvm..

I like scala myself

Anonymous said...

Some people, when they have a problem, say "I know! I'll use the JVM." Now they have two problems.

Don Dwoske said...

In my opinion, you want something lightweight and dynamic with the graphics built right into the language... or as close to it as possible.

REBOL View is fantastically portable and is an easy to use language with an economical syntax.

http://www.rebol.com/prod-view.html
http://www.rebol.com/docs/easy-vid.html

If you choose Java, Mono, Perl, Python, or other heavyweight things you'll be struggling with the language and toolkits and not getting any work done.

Downsides are that the widgets are not 'native' looking and the REBOL interpreter is not open-source. (but it is free).

Jeremy Bowers said...

Build your simulation model in a high level language first, to make sure you've got it right. Then, if necessary, port it over to C.

However, only the simulation process itself needs to be as fast as possible. Even the slowest languages will toss together any simulation description you're likely to run on in a blink of an eye. Build only the most basic simulation bits in C, then leave yourself room to use a higher-level language to do things like "building re-usable components" or higher-level specifications of things.

Then, your choice of GUIs in a high-level language.

You may also want to consider that you may not want a GUI after all. If you've got some sort of mental image of drawing several hundred components and assembling them with a GUI, you should drop it. I've never seen a GUI that can manage several hundred components well that required anything less than man-decades to build. It's a hard problem. Unless your simulations are so trivial that all the components fit cleanly on one piece of paper, a GUI isn't going to cut it.

Also, if your simulations are indeed so simple that they would fit cleanly on that one piece of paper, you probably don't need C speed after all.

At the very least, build the engine and give yourself some way of entering the data (data file possible, though I recommend building it in code with a higher-level language; no data language can meet the flexibility of a language for reducing redundancy, and you'll actually do more work to create a new data language) and "feel out" what you'd want the GUI to look like. I find it likely you'll find that whatever fuzzy conception you had for a GUI isn't actually possible in the real world. (This happens all the time.)

Anonymous said...

Please don't use LCQ. It is still in an experimental state, it uses Qt4, it uses Lisp, so please please don't use it. (I hope this wasn't kind of too aggressive advertising ;-)

Anonymous said...

I'd use Java, as it's quite fast (after startup), portable, and has a great ecosystem.

For the GUI Swing is good (just be sure to enable the native L+F if you use Windows or Linux; the builtin one is just ugly), and NetBeans makes designing the forms very nice and easy. I don't know WXWidgets, but IMHO Java is much nicer for GUI work than other C dialects (except maybe C#, but it has no cross-platform GUI lib).

Be sure to separate models, views, and controllers, which is easy if you use NetBeans.

For the internal code, Java might not be too great, so I'd map your thoughts on paper. Datatypes are nice to model as ML datatypes, and then translate into Java subclass structures (one abstract class, many variants).

If you need more bang, you can always "upgrade" to Scala, but then you lose the nice IDE integration and code completion. So it depends on your needs.

Bruce said...

I discounted QT a few years ago for the same reason. I've re-evaluated it this year for one of our products, and I'm really surprised at how much better it is than the other, similar tools.

Remember, meta compilers are not bad: Visual Studio uses a few of them itself (resource compiler for example). It's really how well the meta compilers work that matters. The QT approach is clean, and all of our developers are loving it.

The QT widgets look great on Mac, Windows, and XWindows. Their designer is easy to use (layouts are a bit tricky at first, but no worse than those from Windows.Forms). The documentation is well above average. And the resulting applications go together quickly.

I'm normally a Gnome user (so I know GTK+ quite well). QT is far cleaner and easier to use, especially on Windows and Mac.

schlenk said...

Take a look at Tcl/Tk.

Its used by a lot of ECAD tools from Mentor Graphics, Cadence and others, and will be useful if you go into the hardware industry.

stefan.ciobaca said...

Thank you all for your insightful comments.

I think I need to clarify my performance concern, because a number of people seem to have gotten it wrong. I'm not very concerned about GUI performance. What I am concerned about is simulation performance. Python is a very cool language, but some things are best left to C++.

As for dismissing some options based on preconceptions, please tell me what they are, so that I can investigate them.

I know about other languages for the JVM and I think it's a great way to go. I particularly like Scala and Jython. However, it worries me that these languages may not be `complete` yet, but I may end up choosing one of them since my project is not really critical and I am free to experiment.

I will look further into Rebol, since it sounds cool, but I don't think it's the right tool for this project.

Jeremy: thanks for your comment. We are in agreement. However, I do want to try experimenting with the GUI. But of course I'm making the simulation usable from the console. After all, I haven't read The Art of Unix Programming for nothing.

My current best choice is to write the GUI in Python (along with an initial version of the simulator) and then write the low level stuff in C++. But I am looking into Scala /Jython.

stefan.ciobaca said...

I do not plan to choose QT, even though it is cleaner than other approaches, because of a simple reason: it's a platform and I am looking for a library.
Trolltech is of course a very smart company and their product is technically very good. But by creating a platform instead of a library they have created a huge adoption problem.

innervision said...

One lib I like quite a lot (although I didn't use it for any professional programming yet) is Ultimate++.

You can get it (along with a very nice IDE) from www.ultimatepp.org. You better go with the latest devel/rcs, as they are more stable and have more features.

The only big problem with the lib is that it's not very well documented, although they are getting better at that every day, and the integrated "browser" in the IDE should be a good helper.

Wiggins said...

I know this whole blog post is just a troll since you dont really care what anyone suggests you've already made up your mind but heres my comment anyway:

What you want is Qt, it is in the language of yaour choice, it provides nice clean cross platform widgets. What exactly are your problems with it?
Meta Compiler? If you dont like "meta-compiling" why are you using C++ over C? why not just write everything in assembler?

And what you have described that you want WOULD be a platform, you want a full blown applicataion, not just a gui to throw together.

the Platformness of qt4 is a bonus since you have no other dependencies, just a qt4 install (which runtime can easily be acquired for any platform)

Use C++/Qt for your low level simulation engine.

integrate a high level language like python or ruby or whatever you want into the simulation part for allowing users to code special modules and such.

Jonathan said...

Rebol seems to be a good choice for your needs.

Anonymous said...

Why not use the right tool for the job, and use a language like ActionScript 3???

User interfaces and graphics are a red headed stepchild added to the family as an afterthought in the languages you mentioned, except for C# ...

Tat-Yuen Hui said...

You can try SmartWin++ (smartwin.sourceforge.net). It is a C++ GUI library with ease of use in mind. And If you combline SmartWin++, Boost, STLport, Loki and ACE, you can get enormous power. Alternatively, you can try to combline different languages, for example, Haskell for algorithms and C++ for GUI. There is tool for that called SWIG (www.swig.org).