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:It's a trade-off

[ClosedSource]

Actually, it's not necessarily a function either. Functions should have a well-defined purpose beyond being just a collection of lines of code. The reason is that when functions aren't well defined they're less likely to be reusable. In addition, when they are created soley to satisfy the "don't repeat yourself" rule they often have to be refactored back to a non-function when the coincidence that caused the duplication of code disappears.

Despite the "constant refactoring" edict, refactoring is really a kind of maintenance optimization and like all optimizations it's problematic if you do it too early.

Dont code GUIs...

[forgoil]

There is no need to code your GUI with todays environments. Simply design it, "draw it", in an editor. If youre doing .NET, Cocoa, or Java it should be a breeze. Doing it all in code will basicly just take time, time you could spend on something better.

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.

Re:I'd be surprised if there was a guide

[ClosedSource]

"even though GUI builders are evil, and one of the very reasons they are evil is they preclude even the simplest refactorings. The bulk of programmers seem to be happy about that."

The whole point of using a tool that generates boilerplate code is that you don't want to mess with it. Refactoring is really a means to enhance maintainability, it doesn't add much value for code you don't intend to modify.

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

Re:GUI's de-evolved

[Shados]

VB6 and Delphi were RAD tools. RAD Tools still exist, and are commonly used. For a lot of stuff, many fields, certain company sizes, certain needs, they ARE "the right tool for the right job". VB6 blows by today's standards, but back then it was pretty cool, if what you needed to get the job done -was- a RAD Tool.

Today there are others. A few years ago I worked with Oracle Developer. Don't know if they changed the name. I hated it, personaly, but a lot of large corporations had success with it. Today I know eDeveloper 10 is quite good, and actualy scales and adapt pretty damn well. Uses declarative programming though, and I can't stand that. Allows you to make stable and fast apps so damn quickly though that it more than evens out for the issues commonly associated with RAD Tools. Not my cup of tea though.

There's more to the programming world than .NET/Ruby/Java/Python/PERL/C++/What-have-you. In many situations, those are overkill. And quite often, it IS a good business decision to go "Lets just use RAD to get our system done, since we're a small company. When we grow bigger, we'll scrap it and do it right". Rediculous for a 30 people company to make a fully extensible, scalable, maintainable system with all the bells and whistles in C++ with 1500 pages of documentation that works cross platform and yadah yadah yadah. Not everyone has these needs.

Again, -I- hate these things too, because the environments I work in DO require the extensibility and maintainability of the more "serious" languages, but not everyone do.

Re:GUI's de-evolved

[ClosedSource]

I agree. I've seen startup companies go out of business trying to do things "the right way" when they could have survived by delivering a less internally elegant solution. Designing for extensibility and maintainability is all about paying more today so that you can save even more tommorow, but there has to be a tommorow for it to pay off.