Software Engineering of GUI Programming? 116
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?"
It's a trade-off (Score:4, Insightful)
Re: (Score:1)
That's right - it's a function waiting to emerge.
Re: (Score:3, Insightful)
Despite the "constant refactoring" edict, refactoring is really a ki
Re: (Score:1)
QFT.
Re: (Score:2)
Daniel
Reliable Software through Composite Design (Score:3, Informative)
Re: (Score:3, Interesting)
I don't agree, however, that Fowler's works are a logical extention of those principles. The fact that Fowler "allows" reversing refactorings doesn't seem like much of a concession. The goal should be to avoid doing additional work that you have to end up undoing later. Since refactoring b
Re: (Score:2)
Re: (Score:2)
This is an interesting perspective.
I think that while pasting a few lines of code is normally harmless, it doesn't follow that a function that replaces a few lines
Re: (Score:2)
I'm against any programming principle that says that anything is "automatically a bad thing". My post was a reaction to the recent movement in software development that tries to substitute absolute rules for good engineering judgement. I consider the "don't repeat yourself" rule to be an example.
Dont code GUIs... (Score:3, Insightful)
Re:Dont code GUIs... (Score:4, Informative)
Re:Dont code GUIs... (Score:5, Insightful)
Mono and Gtk# too (Score:1)
How are Gnomedevelop/KDevelop at simply "painting" instead of "coding"? Anyone know?
Re: (Score:1, Troll)
Now, more than ever: forget Mono.
Re: (Score:2)
Now, more than ever: forget Mono.</blockquote>
Nevar! C# and the
Gtk# however.... meh. Well, actually, I don't have much experience with it so I can't say if it's better than Win.Forms. But Win.Forms *is* infinitely better than Swing...
Re:Mono and Gtk# too (Score:5, Interesting)
That's probably overstating it by a fair margin. ;)
Many parts of C# are awesome, and work very nicely:
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
Re:Mono and Gtk# too (Score:5, Informative)
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
Re: (Score:2)
Wow. You've just made my life easier. :) Thank you!
(I think they generally change the names so that the original implementation remains intact. They did the same thing with DataGrid, for instance - the "upgraded" class (I hate them both, though) is called DataGridView.
While I understand their rationale, I find this nomenclature ver
Debian (Score:2)
Re: (Score:1)
Wh
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Poster is spot-on (Score:1)
Re: (Score:3, Interesting)
# DataSet and DataAdapter are overly complex.
Yup, but there's a direction M$ is going. A DataTable boils down to nothing more than an object[][]. Roughly equivalent to a recordset in COM+ ADO. One big leap is row-level events, which has been infinitely useful to me, as I tend to pass around DataTables a lot in my line of work. I've also found the self-adapting O(n log
Re: (Score:2)
Re: (Score:2)
Why was this moderated insightful instead of funny?
Try this one out (Score:4, Interesting)
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.
Re: (Score:2)
"User Interface Design for Programmers" - Joel Spolsky
"The Design of Everyday Things" - Donald Norman
"New" interface (Score:2, Funny)
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"
Re: (Score:3, Funny)
Re: (Score:1)
if you were looking for errors instead of optional syntax (see here [petesqbsite.com] for clarification), I think you will find my only error is with the line numbering.
Re: (Score:1)
> Who are you calling a n00b?
> if you were looking for errors instead of optional syntax, I think
> you will find my only error is with the line numbering.
Wrong.
> 30 PRINT "Slashdot. News for nerds, stuff thats happening"
Should be...
30 PRINT "Slashdot. News for nerds, stuff that matters"
mike
Re: (Score:1)
Ahhh well, I hope noone was injured trying to copy my code.
Re: (Score:2)
Re: (Score:1)
90 PRINT "PROFIT!"
I'd be surprised if there was a guide (Score:5, Interesting)
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.
Re:I'd be surprised if there was a guide (Score:4, Interesting)
I'd just like to point out that the article you linked is crap. Or, more precisely, it's written by a developer who's apparently never used a GUI design tool. Most of his "problems" boil down to, "You're still going to have to write your own code anyway, regardless of what you do in the GUI builder," which I answer with a great big, "Duh!" In fact, most of his signs of GUI builder use are really just signs that you're dealing with a lazy developer, a non-developer who bought into the idea that he could just drag 'n drop his way to freedom, or a developer (like the author) who's not very familiar with the GUI builder in question and/or has pre-judged the GUI builder tool before even trying to use it.
Granted, 99% of my GUI builder experience has been with Microsoft Visual Studio which is actually very good, so maybe his concerns are valid for other tools. Of his list of signs, Visual Studio makes it trivial to handle the first three (layout management, variable names, and localization), it's possible to fix the fourth one by writing custom controls, and there's nothing wrong with the fifth one (common boiler plate code) though with the use of parital classes in .NET 2.0 Visual Studio does its best to hide that from the developer.
Re: (Score:3, Informative)
So - the original developer, and every subsequent maintenance programmer need to now understand not only the core language, but all of the subtle nuances of the tool that controls the UI in addition to the myriad ways the two interact (or fail to interact). All in the interest of simplifying GUI construction? I think you just
Re: (Score:2)
Re: ...precisely two good GUI designer tools... (Score:1)
I have previously used the Qt designer, up to version 3.3.4, and it was OK. I still found I needed to tweak code and layouts specifically for the target OS. Perhaps that was due to lack of familiarity with the tool.
I simply expect a GUI designer to relieve some of the tedium of hand coding a layout, especially those with obtuse interfaces, like grid bag. If the designer also can provide a way of hooking UI elements
Re: (Score:1)
This could also just be an instance of "quit stalling and try to USE FXruby", and if so, i'm open to hearing that, too.
Re: (Score:1)
Re: (Score:3, Insightful)
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.
Re: (Score:2)
The need for a tool to generate boilerplate code is a sign that either the underlying framework has problems or that your understanding of it is flawed. I don't need a tool to generate GridBagConstraints (talking Java now) because all of the "boilerplate" stuff was refactored up into a reusable class by Sun.
Re: (Score:1)
Re:I'd be surprised if there was a guide (Score:4, Informative)
Re: (Score:1)
Here you see what happens when people do too much GuiDesign.
Re: (Score:2)
I dare hope so, but that doesn't mean that modern GUI builders are good, it just means they didn't get this point terribly wrong. Any technology must lead to good results if one knows how to use it correctly, or it should be directed straight to the thrash can.
Now, assuming that both GUI builders and their alternatives produce good results when used correctly, the question is which is better to
Re: (Score:2)
In other words, constain the design of your UI to the limitations of the GUI builder? I think you pretty much just made his point for him.
Re: (Score:2)
Plus, doing databinding on a radio button frame is a major PITA.
In other words, even if I would ever code by hand, I would still use a dropdown.
Re: (Score:2)
As for the PITA:
- If the list of options come from the database or config file, doing the binding is really an annoyance (creating control dynamically and such). Plus, if you work on desktop app, you need to handle positioning and sizing yourself. Wow, great! Then, the list might one day have too many elements for the screen space you have.
-
The basics. (Score:5, Interesting)
1) Design patterns still apply. More than ever, actually. If you've not read the GoF [wikipedia.org], 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 [trolltech.com] 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.org] 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.
Re: (Score:3, Funny)
Re: (Score:2)
Try to design your GUI so that it can assemble itself (via a layout manager or templating system). This makes
Re: (Score:2)
Object oriented design (Score:1)
Object oriented design techniques work equally well for all areas of software engineering. Don't think there is some "special" technique for GUIs.
Tcl/Tk and Earlier C++ books (Score:2)
Re: (Score:1)
Re:Acccounting package (Score:2)
Digg me down. Wait, wrong site (Score:2, Informative)
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 navigatio
Re: (Score:3, Interesting)
I am so sick of applications, like Photoshop for Windows that has ahrd coded black text for most of it's dialogs. I use a bright grey on dark grey/black colourscheme to preserve my eyes at night and no matter how depressed I or Marvin might be, black on black is not readable.
I think there should be some sort of standard or UI Useability Compliance Organization or something to promote this concept.
Am I
Re: (Score:2)
The only instance where I use hard coded colors? During the debug/testing phase (eg. a big bold green label who's text begins with "todo:")
Re: (Score:1)
From experience, 2 is too low a threashold. Around 4 or 5 is more realistic. Sometimes things are the same out of coincidence, not out of any domain linkage. It takes 4 or 5 before it is a fairly certain and stable rule. 2 also results in a lot of jumping around to read or debug code.
GUI's de-evolved (Score:3, Interesting)
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).
Re: (Score:2)
As someone who's not only designed and developed highly interactive user interfaces ( http://consumer.mci.com/TheNeighborhood/res_local_ service/jsps/callmanager.jsp?subpartner=DEFAULT [mci.com] , just to name one ) for almost 20 years, but also developed applications in both of those languages ( and many others ), I can tell that your statements are writt
Re: (Score:3, Insightful)
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 k
Re: (Score:3, Insightful)
Re: (Score:2)
Now as for RAD tools, there's plenty of RAD tools for Java besides those, there's Netbeans ( or for Eclipse, the Eclipse VE, Jigloo or WindowsBuilder Pro ) or IntelliJ Idea.
Sure there's a frameworks for creating scaffolding for applications within Ruby, et al., but frankly much of that is strictly useful for creating boilerplate code
Re: (Score:2)
Oracle Developer also was a large framework, I was thinking about the actual RAD tool, which was a near code-less environment (except for some PL/SQL, there was little no way of adding any code beyond PL/SQL). The result was an application that required a special proprietary runtime (it ran inside another MDI software). I used JBuilder for several years too, it has nothing, -nothing- t
Re: (Score:2)
Re: (Score:1)
For the former, VB is a nightmare at least to adapt to applications needed to operate in non-homogenous environments. If you're all M$, fine, but there, you're locked in.
99.9% of all business PC'
ActiveX, Delphi, Type Library Editor (Score:3, Informative)
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 y
Re: (Score:2)
The points you make are always the defense positions taken by those proponents who have in one way or another a vested interest in their prol
ActiveX development alternatives (Score:2)
As an alternative to ActiveX, I am looking at Java Swing. But it will be a while before I get my stuff rewritten, so I have still have an interest in the Windows API and in ActiveX.
The original discussion was that Delphi was good for arranging pretty widgets but if you wanted to develop new widgets you had to drill down to C++. My suggestion was that in some regards Delphi may be a better development environmen
Re: (Score:2)
And Windows Presentation Foundation is coming out quite soon.
Both of those things make VB/Delphi look "hard" when it comes to GUIs. I'm sure the Unix land has equivalents, too.
Re: (Score:1)
In my initial experience, I am not impressed with it. If you go "outside the box" for any reason, you get stuck with cryptic errors talking about some internal gobbledy-gook being out of whack.
User Interfaces. (Score:2)
Make sure to look thro
Re: (Score:2)
Do you really need to maintain it? (Score:1)
So I think it's best to take as much as possible out of the UI code and make it a really simple, almost disposable, client of really good APIs to the rest of the system. Simple is not
Apple? (Score:5, Interesting)
Apple's User Interface Guidelines [apple.com]; adapted from the NeXT/OpenStep Interface Guidelines (PDF) [gnu.org].
There's also the Classic "Macintosh Human Interface Guidelines" for System 1 through OS 9 (have to hunt it down yourself), GNOME's HIG [gnome.org],KDE's [kde.org], and Tog's [asktog.com].
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.
What kind of repetition? (Score:1)
And for chrissakes, remember this is a HMI (Score:3, Insightful)
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: (Score:2)
Threads and GUI (Score:2, Informative)
Done it (Score:1)
A good article to start (Score:3, Informative)
code reuse is NOT the problem (Score:2)
so that I can learn how to reuse code, and build my class hierarchies over the one provided by the toolkit?
Believe me, desiging a class hierarchy is NOT a problem, it's much more difficult to learn to design good GUIs, after all they are the 'contact point' with the user, so clarity, simplicity, predictability, etc are the real challenge, it takes a lot of imagination and experience to design GUIs that doesnt get noticed!
Re: (Score:2)
If the original poster is having problems with designing reusale code, it is not because of the GUI, it is because he needs help with design. I'd suggest getting a design paterns book and maybe even a book on GUI design. Try the orielly.com web site, as they have some. For web design, try a book called 'defensive
Adobe's Adam and Eve (Score:1)
Has Anyone tried it out ?
It looks like they take the approach of using a domain specific language [martinfowler.com] for building the GUI.
Simon.
My suggestion (Score:1)
If you're going to have several smaller windows in your app (dialog boxes and such), I would suggest possibly creating some wrapper classes that have the the basic dimensions and alignments for the template you're trying to follow, so that you're not repeating code like assigning sizes and buttons and such.
As far as design goes,
Re: (Score:2)
Eclipse RCP (Score:1)
If you haven't heard of these things:
* SWT is a relatively low-level cross-platform widget toolkit. It is at around the same level as Qt, GTK+, and the GUI bits of MFC.
* JFace adds a layer of abstraction on top of and is built to work with SWT...helping you effectively split your widgets and the data feeding them in nice ways. It also provides a whole lot of convenience classes for doing common things more easily.
* Eclipse
Checkout Turbo Delphi / C++Builder tools (Score:2)
VCL is exceptionally simple but yet very robust and customizable. Search for "Delphi Super Pages" for additional VCL components, sample code, and all sorts of other goodies.
Decouple It (Score:5, Informative)
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.
Nesting and Abstraction (Score:4, Informative)
Of course, HTML is not intended as a language for describing native GUIs, so it has some limitations there. Fortunately, there is a variety [mozilla.org] of [xaml.net] XML formats [tigris.org] for describing [jamesh.id.au] real [gnustep.it] GUIs [apple.com].
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...
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
C++ and Java are extremely static languages. The proliferation of boilerplate and superclasess/interfaces is just amazing, plus you get extra boilerplate because of the lack of support for functions and closures. Everything gets implemented as a class instance, and every time you want to make something dynamic (what isn't dynamic in a use