LUNY.CO.UK

As said before choose a language that exists on plenty of platforms. Also use an object oriented language, this naturally lends itself to GUIs. GUIs are made up of objects, which in turn own children and so on, exactly like an OO language. The obvious choice is C++ or Java, but there are plenty or others and new languages coming out.

C++ strengths lie in its availability, but being an advance language it has some dangerous pit falls in what it allows a developer to do. Java on the other hand is just as available as C++ and has eliminated most of the C/C++ pitfalls, however its downside is its speed. Java is a byte-code interpreter, so it does not run native like a compiled language such as C++.

Think carefully and use the language you are most comfortable with. See how many different processors your choice can run on. C++ & Java runs on all of the most common processors around giving you a chance to use anything from a PC, a smart-phone or even an TV.

For some capabilities you are going to need to use a 3rd party library or two, such as JPEGs & PNGS. These are large and complicated libraries so there is no point in spending time writing you own code when open source libraries are available. Libpng is a good example, it is an open source library which displays PNGS to a pixel surface of your choice. Some platforms will come with the library available, but failing that the source is also available so you can compile it directly into your code or as a separate library.

However, if you do use any of these libraries, remember to make it easy to drop in an alternative. Libpng requires you to fill in some stubs as it only knows how to expand a PNG into a bitmap. You have to display it correctly on the screen. Therefore it is best to have these rendering functions as part of your graphics device class, keeping all of your changeable code together for an easy change when porting to a different platform.

Secondly the lib PNG has its own API, which will differ to the JPEG API.Create your own simplified API which creates a common interface between the two. For instance have a simple load function Load(filename, buffer) or a call which displays the image Display(buffer, x, y). Create a base class to define this interface then override it for each type of image renderer you require. This way when you drop in another renderer you just need to override the base class with a new one which calls the new library API.

With this in place, the final build only needs to add which renderers it requires to its makefile without too much, if any, source code changes.

When you are creating your GUI, think of how another developer might use your GUI. Imagine how they can add resources and create layouts and design screens. What is the easiest way to enter this information? Expect the developer to have to build more than one GUI release. How can they decide which resources to use for each build?

Also think about where the developers additional source might go and how can they easily add it into a build. Since they might be adapting or even replacing your base objects, it needs to be done easily. Also make it as simple and straight forward as possible to move your GUI onto a new platform. Keep all the platform specific code in one place, away from the portable code. Anything common should be in a base class, with the developer only having to override the functions which require changes.

Finally, always think in layers. Create a diagram and layout where you think the module fits and with which other modules it talks to. For instance the GUI controls never calls into the device drivers directly, they always go via the graphics context. Never call directly to a 3rd party library, always create a shim, as mentioned before. Then if you swap out the library, you only have change that one layer instead of going through all of your code, and any developers code, in order to change single function name. Believe me 3rd party libraries do change their APIs from time to time, and a thousand lines of compile errors are not fun.