Lit Window Productions

simpler UI Coding




RSS Feed
What’s this?


Fast, easy dialog editing and code generation with Anthemion’s Dialog Editor for wxWidgets...

RapidUI – taking UI coding to the next level

Welcome. This article describes the motivation behind “The Lit Window Library” and the “RapidUI” mechanism in particular. I write about the frustration out of which the idea was born, the means and methods how I want to achieve the “next level of UI coding” and why I think RapidUI is revolutionary, rather than evolutionary.

I’m fed up...

I am fed up with solving the same old problems, writing basically the same old code over and over again. How many times have you written one of these?

  • LoadSettings, SaveSettings
  • FillListBox, FillListControl
  • OnButtonAdd, OnButtonModify, OnButtonDelete
  • for (i=0; i<something; ++i) { copy element to somewhere }
  • OnUpdateMyTextBox

Ask yourself, how much has GUI coding changed since it became popular some 12 years ago? The biggest change was probably in the early 1990ies, when C++ class libraries took some of the drudgery out of writing VLSS – Very Large Switch Statements – replacing them with the famous OnSomething methods that litter every source file. Since then? The requirements got more and more every year. We had to learn different APIs every two years. The look and feel of some widgets has changed with every new release of that certain operating system almost everybody seems to be using. But behind the scenes? In the source code editor? Nothing. We still diligently enumerate all member variables of a structure to write them to a file or read them. Or iterate over a vector to or database cursor to copy its content into a list control so the user can select one item. And when writing the next application, no, even when coding a new dialogue in the same application we write them again: basically the same lines of code with slightly different member names and perhaps a slightly different structure.

I have been writing hundreds, if not thousands of these little functions in the last decade and I am fed up with it. It is almost the year 2005, our computers have gotten incredibly more powerful and the user base has grown beyond anything anyone would have expected back in “the good ol’ days”. But we are still coding with the same old tools and libraries, ideas and paradigms as when the first graphical user interface came out.

Application generators, software factories, reuse, higher level languages?

“Using XYZ makes programming your application a snap!” – “Dminor is the best thing since sliced bread!” – “Increase your productivity with the new, all-powerful code generator/design tool/UML diagram – roundtrip engineering/software modules...” – “GridWonderControl, the best grid control you can get for money...”

You’ve probably read your share of announcements for these “great breakthroughs” in programming. (And to be fair, the one you are reading now is probably just another one to you.) So far it hasn’t happened. These solution help ... a little. In my experience however they are just not flexible enough.

Using a code generator forces you into a code structure that was conceived by the application generator vendor. Around 1995 IBM’s Visual Age C++ compiler for OS/2 included a “Visual Builder”. It let you connect GUI widgets with each other and would show little arrows between them, where one widget would react to an event sent by another widget. I thought it was a great idea until I saw the code that was being generated. Bloated, unreadable and unmaintainable by a human being.

Visual Basic and Delphi both have quite a market for specialized GUI widgets, aka ActiveX controls, OCX, OLE, whatever... The idea here is that you buy a couple of these components, throw them together, add a little code and you’re done. Not in my experience. Just hearing “Variant” data type makes me shudder.

All these tools have one thing in common: If you want to use them, you have to do things their way. As soon as you start leaving the designated path you are headed for trouble. And in all real world applications that are a tiny bit more complex than “hello world” or “tea timer” you will have to leave that path eventually. No tool you can buy was designed with exactly your requirements in mind. And that’s were the trouble starts and most tool solutions eventually break down.

What I want...

I want something that lets me do things my way, that doesn’t interfere with my way of designing an application and that lets me extend it easily. It should further be small, very simple to use.

Here is a short list of requirements a solution has to meet to make me happy:

  • It has to be extremely flexible.
  • It has to be able to use my data definitions.
  • It must not force any design decisions on me.
  • All tools/libraries/standard solutions will eventually break down. When this happens, it has to provide a smooth transition between the area it can cover and the methods I have to handcraft.
  • It has to enable me to really reuse code I have written.
  • Writing reusable code must be as (or almost as) simple as writing “normal” code.
  • It has to have a large library of frequently occurring coding patterns that I can use.
  • Using these patterns must be a lot easier than coding them again.

Read on: How it works...

[Home] [Products] [Shop] [Knowhow] [Library] [About]

© 2004, Hajo Kirchhoff, last modified Mar 06, 2008


back to top

webhosting by netissimo