Slashdot Mirror
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?"
Errr... there are still controller classes; those nastly little things that sit behind your gui. The last I looked, you had to do at least SOME coding. But in general, the ui elements themselves are just painted now.
The article you mention is total bullshit to me. If one know how to use a modern GUI toolkit correctly, then his whole point on code reuse/repetition disappear. I mean, has he ever heard of UserControls? Of MasterPages/Forms? What about using a single DropDownList instead of multiple RadioButton? And when he shows how he could reduce the code size by using a for loop, it is totally bogus. This code is LESS efficient that the generated one!
Intelligence shared is intelligence squared.
Generics, for instance, are a much-needed feature - but Microsoft didn't bother to implement it for ArrayList, the data structure that I use most often.
.NET Framework including ASP.NET and who all knows what crap you don't need, it probably would have replaced C++ for many applications already. Something like perl2exe for C# is what I want. Just bundle the runtime and the JIT and your code up in one nice tidy ready-to-run executable. That would do wonders for the adoption of C#.
ArrayList is still its original, non-generic self for compatibility reasons, but the new List<> class is its excellent replacement in the System.Collections.Generic namespace, along with the generic Hashtable replacement, Dictionary<,>. Don't know why they felt the need to change the names, although ArrayList->List was an improvement...
Other than that, I agree. I'd just put events and delegates farther down under the "completely suck" section. They were really botched and it makes certain things a lot harder than they should be. Also, I'd mention the single greatest thing about C#, IMHO its saving grace: C/C++ interop. The design of the interop with legacy code is nothing short of brilliant. It's five minutes work to wrap and call a random C function, no matter if it takes pointers to weird structs or even a callback! And because of that, C# actually stands a chance of displacing C++ as the language of choice for Windows applications.
If only Microsoft had fixed it to allow distributing C# applications with their own stripped-down runtime included, instead of requiring administrative install of the full 20+ MB
Firebug. It will make your jaw hit the floor.
I didn't see this mentioned in other posts, but I think it's very important:
Decouple your GUI from the code that does the work.
I really don't have a lot of experience with GUI programming, but I do know that there are many different toolkits on different platforms, each comes with its own guidelines, and these guidelines are subject to change over time. At some point down the line, you or someone else is going to want to change the GUI, while keeping the functionality. Moreover, you or someone else may want to drive the application from a script, or from the command line (some platforms may even require one or the other for applications that are considered good citizens). In other words, your application _is_ going to have more than one interface - make sure that is easy to accomplish.
Please correct me if I got my facts wrong.
I've built a lot of web pages, and this has made me realize that it's incredibly quick and easy to whip up GUIs with HTML. The experience was much better than with the GUI builders I had used, and certainly beat coding GUIs by hand.
Of course, HTML is not intended as a language for describing native GUIs, so it has some limitations there. Fortunately, there is a variety of XML formats for describing real GUIs.
What makes XML so great for describing GUIs is that it's so good at describing nested objects. If you think about it, that's exactly what GUIs are: you've got your windows, with a bunch of widgets in it, one of which is a scrollable area with more widgets in it, etc. This is naturally described by an XML tree that contains all these widgets, with some attributes used for connecting them to the application; e.g. ids to allow the application to reference widgets, and embedded code to let the GUI respond to events (e.g. HTML's onclick).
Where many XML GUI languages fall short is in that they don't provide methods for building new abstractions. If you have a lot of subtrees that are all very similar (say, a frame, a title, a content window, and a hide and a show button), you'll completely have to code each of them in full. Any programming language worth its salt will provide a way to abstract over this (functions!), but I think the realization that XML GUI descriptions (and HTML documents!) are programs hasn't fully set in yet.
Next time I'm coding a GUI, I'll be generating the XML from a proper programming language. I've had good results with Lisp before...
Please correct me if I got my facts wrong.