Friday, December 26, 2008

Building a GUI for an embedded system.

I'm building a HMI for an industrial control application, in a hurry. I'm faced with some choices:

#1. Use a GUI system on top the Unity 3D RAD platform.
#2. Use a 'standard' toolkit, like Windows Forms, GTK or QT.
#3. Build a GUI system on top of Pyglet.

Number #1 would be great to use, because it will let me use 3D elements as GUI items, and builds a very slick looking product. Unfortunately it doesn't work well with the touchscreen, because of the way it's GUI system works. It assumes you are always using a mouse. Because of this, I'd have to work-around the problem, which is an unknown and a risk.

Number #2 would be ok, because I could use Python, and it will get me up and running quickly. However, because I'm using a touchscreen, with no keyboard, most of the pre built widgets would be useless. I'd need to build new custom widgets, which almost negates the advantage of using an existing toolkit.

Number #3 is a risk, because there is an amount of new code I would have write and test. I can't just dive in and write the application. However, I have written lots of OpenGL GUI code before, which I can draw on, and I can make it look much better than Number #2. I can also build the widgets explicitly to work with touch screens, which should make for a better end user experience.

I'm going with #3.

6 comments:

Anonymous said...

You should probably take a look at the Enable package which sits atop Kiva (which now has a nascent GL backend, among others).

http://code.enthought.com/projects/enable/

dan said...

Take a look at Clutter too:

http://www.clutter-project.org/

René Dudfield said...

Sounds like a fun project :)

Some parts of your reasoning got me wondering...

I don't see why existing widgets don't work on a touch screen?

A lot of things like radio boxes, trees, tab views, select boxes etc work fine with touch screens. If you need just one of these things it will probably save your time.

There doesn't seem to be any testing framework for pyglet applications? Does your gui code need to be tested?

It's always good to go with what you know :) Especially if you don't have experience with qt etc. That reason alone is reason enough to choose over qt.

Requiring opengl seems a bit weird for embedded systems.

Do you need multi touch? SDL 1.3 has some nice multi touch support these days. I haven't tried multi touch stuff with qt/pyglet... but I'm sure there's some way to do it.

I've seen some cool wireless controllers using ipod-touch/iphone... that could be another option :)


However... the main question you should ask yourself... does qt have a good particle system? NO! then your choice should be obvious.

Henry said...

You might as well take a look at Python/Edje. There is a tutorial available at http://wiki.enlightenment.org/index.php/Creating_Edje_User_Interfaces

Unknown said...

Simon,
whatever you choose to do, please make it open source.
Your code is good and clean, other people could learn from it or use it as a fondation to build something bigger.

Simon Wittber said...

@illume

Most widgets in a traditional GUI are too small to be accurately pressed by a finger, especially select boxes, radio buttons etc. By making bigger widgets, less mistakes are made with the touchscreen.

I'm using OpenGL because we are controlling things in a 3D environment, and will likely need to display spatial type things. And yes, I might even use a particle system to represent collision information! :-)

Popular Posts