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?"
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.
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.
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?
Not sure if it is exactly what you are looking for, but I think a good starting place would be Designing Interfaces by Jenifer Tidwell from the O'Reilly collection. It helps if you are already familiar with design patterns, as the book casts its concepts in terms of patterns.
I would think that if you are an experienced Software Engineer and programmer, you would be much better served by something targetting the fundamentals of interface design. You can apply what you learn to any language or toolkit you know now or learn in the future. If you target a particular language or toolkit from the beginning you will limit yourself and make it harder to apply language-specific or toolkit-specific things to a different language or toolkit.
I designed a new web browser, it uses a professional interface, here is the code:
10 INPUT "Enter the URL: "; U$
20 PRINT "Finding "; U$
30 PRINT "Opening "; U$
30 PRINT "Slashdot. News for nerds, stuff thats happening"
40 PRINT "1. Ask Slashdot: Software Engineering of GUI Programming?"
50 PRINT "2. Ask Slashdot: Can a Manager Be a Techie and Survive?"
60 PRINT "3. Your Rights Online: China Jails Porn Site Leader For Life"
60 PRINT "4. Close"
70 REM
80 INPUT "Select your destination: "; I
liqbase
Most people don't seem to think about refactoring their GUIs; already there's one post here telling you not to code your GUIs but use the pathetic drawing tools to create them, 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.
My experience is that there really isn't anything special about GUI refactoring vs. any other kind of refactoring, at least in the languages I use. That may be a factor; dynamic languages like Python or Ruby seem to be a lot easier to implement "Don't Repeat Yourself" in. You may find you'd be better off switching to one of them, especially if you're trying to work in Java, with seems to elevate repeating yourself to a moral imperative.
But beyond that, I don't really see what's special about GUIs.
The other thing is that when you are first learning an environment, you need to cut yourself some slack. No matter what you do, your first few cuts will suck as you are getting your bearings. I'm all about refactoring and testing, but when I recently picked up Django, I didn't worry about either at all in the first week. Now I have to go back and re-examine everything I did and get the testing going for it, but I don't see any practical way to avoid it; testing my initial garbage would just increase the investment into code that I'm basically throwing away anyhow. (As I have a lot of web experience, that's probably faster than usual; any other framework type would probably take me longer.) You may find that you have built "one to throw away"; consider actually doing so.
Alright, I'm a little busy right now so I won't go into as much detail as I'd like, but here are the basics as far as I understand them.
:) Hopefully other people will have more details to give you.
1) Design patterns still apply. More than ever, actually. If you've not read the GoF, it features a pretty advanced example centered on the design of a rich text editor. You will probably want to dive deeply into the workings of the Model-View-Controller pattern and the related design constructs. The MVC pattern is not the be all and end all of GUI design, and there are many cases where the articulation between View and Controller
2) You may not now it yet, but you want loose coupling. Loose coupling means that, essentially, when a widget's state change, it will report on that change, and some interested party will be notified about it, and neither will have to know anything about the other. Many toolkit nowadays come with good signal and slot mechanisms to implement loose coupling. Understand them, and use them. If you find the sender of a signal and the receiving slot need to know about each other, you may want to go back to the drawing board as suggested in point #1 above; it is usually not necessary.
Conceiving GUIs is not all about the underlying software architecture, though; a good chunk of the work of making great interfaces is in the designing of the GUIs themselves (which is why you want loose coupling -- you WILL have to be flexible against changes as you experiment). I will let others fill you in about that. Quickly: read usability guidelines and get a feel for why they suggest what they suggest. Align your widgets! NetBeans is good for this, IIRC. Use GUI designer tools, experiment more.
That's all I can think of off the top of my head, but there's already a lot for you to chew in there.
All in all, it boils down to the usual rules of engineering: the second rule is to know what works, and the first rule is to know why it works.
-- B.
This sig does in fact not have the property it claims not to have.
I don't have any links to provide, but these few tips might be useful:
1) Don't duplicate code. The second time some functionality is used, create a library function. Try to think of the variations required and maybe add extra parameters to the function to cater for them.
2) Be consistent in your approach (similar wording on dialogues, standardized placement of objects, consistent use of terminology).
3) Think of your user. Determine your minimum resolution (eg 800x600). Will some users want keyboard navigation/use of your application?
Sorry if this is stating the obvious, but these 3 are rather important on my product (ASP.NET/C#/JS).
GUI's used to be simple in the VB/Delphi days: drag and drop widgets, and then set attributes and fill in methods (on-click, etc.). One used to spend a only few days building GUI's, now they take weeks and months to get how the customer expects them.
Some argue that such tools do not scale for different screen sizes. However, it is possible to build a "stretch zone" so that key widgets can stretch. But even if nested-based GUI's (like HTML) are used, it should not significantly change the nature of the method/attributes setting approach.
People seem to attack the VB/Delphi approach with elistist-sounding rhetoric, but none of it stands up to scrutiny. I think they are just defending their high-cost feifdom. The VB/Delphi style was near the pinnicle of GUI development (minus the stretch zones) and we went backward instead. Java, Smalltalk, and Web approaches ruined a good thing. MVC is a mess only a mother could love.
I think VB/Delphi-style will return one of these days because it was K.I.S.S. done right. GUI's are inharently visual, and thus visual design tools result in the most effeciency and closest match to the domain at hand (Visual GUIs).
Table-ized A.I.
Some resources:
Apple's User Interface Guidelines; adapted from the NeXT/OpenStep Interface Guidelines (PDF).
There's also the Classic "Macintosh Human Interface Guidelines" for System 1 through OS 9 (have to hunt it down yourself), GNOME's HIG,KDE's, and Tog's.
Without reading through them all, I can't point out where they address BPs for reuse, management, etc., but I know it is touched on somewhat (although from a NeXT slant) in Apple and NeXT's guidelines.
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
-- Butlerian Jihad NOW!
That's probably overstating it by a fair margin. ;)
Many parts of C# are awesome, and work very nicely:
- GDI+ is extremely easy to use and predictable.
- I like the way they've organized System.IO and System.Collections.
- The Win.Forms control set is very, very well-done.
- XML web services and Regex are also quite passable.
- Reflection is nice, even though I don't often have a chance to use it.
- ADO.NET's simple classes (Connection, Command, DataReader) are very straightforward, and I use them all the time in my database stuff.
- The Setup and Deployment projects are absurdly easy to use. I love it!
Other parts are so-so. They work, but they're not really intuitive, and I frequently find myself referring back to previous projects in order to remember how it works. Examples:- System.Security.Cryptography, for instance, has a whole lot of junk. When all I want is to generate a set of RSA keys and encrypt something, I still have to refer back to prior code samples.
- Their weird proliferation of Stream types, with all of those weird Formatters, is very confusing. I don't like it.
- Globalization has a lot of byzantine stuff in it that I find very confusing.
- DataSet and DataAdapter are overly complex.
- Events and Delegates are a little too crufty. I don't like the syntax (event += event handler? are you kidding?), and I don't like the fact that if the event doesn't have at least one subscriber, it's Null, and will thrown an exception if you raise it. That's stupid.
Then there are the parts that completely suck:- Resource files? Totally botched! I still have no idea how to create a stupid resource file containing some bitmaps, and have it bundled into the application.
- DataBinding. It is practically impossible to glue a textbox to a string, and have bidirectional updating. I don't understand how MS could have so badly wrecked this stuff.
- The credentialing (Code Access Security, User Security, etc.) is so hopelessly complicated that I won't touch it with a ten-foot pole.
- ASP.NET is very, very, very clunky. None of the controls work right, or in a predictable fashion. They don't even work anything like their Win.Forms counterparts! I can design very beautiful Win.Forms GUIs, but my ASP.NET projects always come out looking like third-grade HTML projects. Terrible!!
I had big hopes for C# 2.0 - but it seems to be a little less stable and predictable. 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. And the new ADO.NET stuff is hopelessly complicated and useless.So despite its flaws, C# is still the drop-dead easiest API I've ever used. I've written several dozen projects in it, and I will continue to use it until something cleaner comes along. (I'm not holding my breath on that one!)
- David Stein
Computer over. Virus = very yes.
Something I've learned the hard way: Never modify any GUI stuff outside the main event loop thread. Well, in Win32 it is possible to get away with it (but you must know what you're doing - i.e. painting to a back buffer is OK, but not drawing into a window). In Swing/AWT you can use SwingUtilities.invokeLater(Runnable) (don't pass anything that extends Thread to it or you will make uncollectible garbage). There must be something similar in the other GUI frameworks out there.
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 wholeheartedly recommend this Martin Fowler's article to start with.
As the book predates the widespread use of OO, it has a kind of proto-OO or proto-object in the form of "communicational" modules -- collections of functions that operate on some common data organized in a data structure or a name space. The communicational-strength module, of which there is a lot of support in Modula-2 and pre-OO Ada, is kind of like a static or perhaps a singleton object, and the reason for this kind of programming is that back in the day dynamic memory allocation was regarded as being fraught with peril -- either too expensive or too risky in terms of heap fragmentation. Remember also the computer speeds and amount of memory that we had compared to today. Classes and their objects are really the communicational module applied to where you have good heap management algorithms and perhaps even GC as well so you dynamically allocate an allow multiple instances of things and don't worry.
I wish there was a latter edition of "Reliable Software through Composite Design" that addressed OO in some ways, but Martin Fowler's works on refactoring comes close. What I also like about Fowler is that all of his refactorings are reversable so if you find that you have too many code snippets in functions, inlining the code snippets and eliminating the functions is an "allowed" process instead of something you are scolded into never doing.
As to cut-and-paste, whenever you see yourself using the text editor to copy any block of code to replicate the same functionality, you are asking for some kind of trouble at some level. The whole problem with cut-and-paste is that your code is littered with multiple copies of the same function, perhaps with some minor variations, and if you have a bug in that sequence or need to revise that common functionality, it is a lot of work to search it all out in your code and fix it.
On the other hand, many times that repeated sequence of code doesn't lend itself to a proper kind of function and you have so many customizations of that function or flag parameters to that function (Glenford Meyers really lays into flags as function inputs and explains why -- I guess Microsoft didn't read his book when doing the Windows API).
A lot of the idioms of programming languages -- loops, functions, objects, macros, anonymous functions, etc -- are efforts to avoid cut-and-paste, and if you are programming in a weak programming language (dunno, like .bat or perhaps VB), you end up with cut-and-paste to do the job rather than wrestle with the language. At some level, some degree of repeating yourself in code is unavoidable and introducing higher-level languages (closures? functional programming?) to avoid this may be unavailable or perhaps in itself introduce obfuscation if these features are generally not known to your maintenance programmers. So if you are left with some cut and paste, don't sweat it.
ActiveX is a remarkably powerful system for visual component software -- restricted to Windows, yes, but supported by many programming languages ranging from VB through Delphi to Matlab. It is also remarkably crufty so to either develop for it or to use it you end up using some form of "wizards" and automatic code generation. And yes, the use of ActiveX on Web sites, especially malicious Web sites is evil, but such things like Flash and some of the free anti-virus sites are delivered through ActiveX. You could also disable all Internet ActiveX and still be able to use client apps on your computer using ActiveX -- there is hardly a major Windows app that doesn't use ActiveX at some level anyway, so if you are to dismiss ActiveX, there is little you can run under Windows.
Delphi is a remarkably powerful tool for developing ActiveX controls as well, and I like it better than the VS/VC++ approach because I find it to be more flexible in tinkering with COM interfaces until you are ready to publish the control. Delphi ActiveX development requires some faith in wizard-generated code (actually, GUI development in Delphi is remarkably free of wizards and auto-generated code because the VCL base classes have so much of the functionality in them, but ActiveX in Delphi requires it). You will also have to become friends with the Type Library Editor -- the Delphi way of writing and maintaining the IDL code that is the plumbing of COM and ActiveX. The Type Library Editor is buggy and has its quirks, but I find it much more powerful for inspecting and modifying COM interfaces than any of the MS tools.
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.