Software Engineering of GUI Programming?

cucucu asks: "After ten years of programming for the network, I started programming a GUI Desktop application. My problem is most GUI tutorials out there are nothing more than a taxonomy of buttons, dialogs, and check-boxes. So as I checked GUI toolkits, I found that I can easily learn all the widgets, layouts, callbacks, and the like, and start coding a GUI application. However, very soon I found myself repeating code all over the place. Is there a good guide (online or off) for the Software Engineering aspects of GUI programming, so that I can learn how to reuse code, and build my class hierarchies over the one provided by the toolkit?"

Comments

It's a trade-off

[ClosedSource]

In recent years the well-understood trade-off between gratuitous code repetition and gratuitous function/class creation has become one-sided in favor of the latter. One should avoid unnecessary code repetition but a few lines of code repeated in several places is not necessarily a class waiting to emerge.

Re:Dont code GUIs...

[cerelib]

I do Java Swing GUIs and I tend to agree with you. The eclipse visual editor plugin makes GUI creation very easy, but it has it's limits. Almost every time I have used it, I have hit some point at which I wanted to do something that the visual editor did not understand. When I hit that point, I have to get in and code it by hand. Since I learned how to do it from code when I started, this is not too much of a problem. So it does help to know what the code means.

And for chrissakes, remember this is a HMI

[thoglette]

The other posters have pointed out that GUI development is a mature art and not much different to other SW problems. It is also incredibly repetitive.

The really difficult part is to make your GUI usable - particularily if your GUI contains any autonomous information (eg. alarms); information from disparate sources/applications and/or your underlying application is complex (eg. a combat system)

At that point you really need to workshop with your stakeholders on use cases;

How many clicks are needed to get to any function?

How well trained/tired/busy/stressed are your human operators?

How many modes of operation are there?

How are you going to manage "status" and "alarm" displays across the suite of screens?

What happens when some application starts struggling/crashing/spewing data?

Training and documentation (user manuals, trainer manuals, debugging manuals) also need to be considered - it's all part of the experience.

At the pointy end of the business, various layouts/schemas are compared by measuring operator hand and eye movement loads!

Ps - For any reasonably complicated GUI you will want an API between your text/visual _specification_ and your code