Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming

Software Engineering of GUI Programming? 116

Posted by Cliff from the GUI-coding-is-very-repetitive dept.
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?"
This discussion has been archived. No new comments can be posted.

Software Engineering of GUI Programming? More

Software Engineering of GUI Programming?

Comments Filter:

  • It's a trade-off (Score:4, Insightful)

    by ClosedSource ( 238333 ) on Saturday November 25, 2006 @05:05PM (#16986464)
    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.
    • a few lines of code repeated in several places is not necessarily a class waiting to emerge.

      That's right - it's a function waiting to emerge.

      • Re: (Score:3, Insightful)

        by ClosedSource ( 238333 )
        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 ki
        • refactoring is really a kind of maintenance optimization and like all optimizations it's problematic if you do it too early.

          QFT.

        • Re: (Score:2)

          by KDan ( 90353 )
          Agreed... factoring the "lines of code" into a function without thinking about some sort of higher purpose reason why that function needs to exist is a bit similar to thinking "I need a music in all the rooms of my house, and i already have a car radio, so i'll just copy that and reuse it in all the rooms"... it might make sense at first but it's a maintenance nightmare waiting to happen.

          Daniel
        • My all time favorite software engineering book is Glenford Meyers, Reliable Software through Composite Design. The book predates OO and is based on a module/function tree/hierarchy model of a software system. The book comes up with these module "strengths" ranging from "coincidental" (taking reoccuring sequences of code and calling it a module -- considered weakest reason) to "functional" (making a module out of code that has a simple declarative sentence description -- considered the strongest reason).

          • Re: (Score:3, Interesting)

            by ClosedSource ( 238333 )
            There were number of books that covered the same issues as "Reliable Software through Composite Design" and my appreciation of this issue originated from reading them. To certain degree we have a common frame of reference.

            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
      • Only if that makes the code easier to read.

    • Re: (Score:2)

      by hey! ( 33014 )

      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.

      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

      • "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 of code, or even a fraction of a line of code, is automatically a bad thing."

        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)

    by forgoil ( 104808 ) on Saturday November 25, 2006 @05:05PM (#16986466) Homepage
    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... (Score:4, Informative)

      by dave1791 ( 315728 ) on Saturday November 25, 2006 @05:15PM (#16986566)
      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.

    • Re:Dont code GUIs... (Score:5, Insightful)

      by cerelib ( 903469 ) on Saturday November 25, 2006 @05:30PM (#16986676)
      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.
    • Don't forget Mono and Gtk# too!

      How are Gnomedevelop/KDevelop at simply "painting" instead of "coding"? Anyone know?

      • Re: (Score:1, Troll)

        by MaggieL ( 10193 )
        Don't forget Mono and Gtk# too!

        Now, more than ever: forget Mono.
        • <blockquote><blockquote>Don't forget Mono and Gtk# too! </blockquote>

          Now, more than ever: forget Mono.</blockquote>

          Nevar! C# and the .NET framework are things of beauty! <br/><br/>

          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)

            by tambo ( 310170 ) on Sunday November 26, 2006 @02:02AM (#16989920)
            Nevar! C# and the .NET framework are things of beauty!

            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

            • Re:Mono and Gtk# too (Score:5, Informative)

              by modeless ( 978411 ) on Sunday November 26, 2006 @04:51AM (#16990434) Journal
              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.

              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 .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#.

              • Re: (Score:2)

                by tambo ( 310170 )
                ...but the new List<> class is its excellent replacement in the System.Collections.Generic namespace, along with the generic Hashtable replacement, Dictionary<,>.

                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

              • ``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 .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#.

              • Re: (Score:1)

                by Snives ( 207067 )
                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 .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#.

                Wh
                • I'm not talking about installing it automatically. I'm talking about a way to package C# applications such that merely executing them does not require the .NET framework to be installed. There's no reason simply running a program written in the C# language should require poking around in system directories and installing crap into the OS. Of course, every program packaged this way would have its own separate copy of the runtime. But they wouldn't need the whole framework, they could just bring the (smal

            • Re: (Score:2)

              by allanj ( 151784 )
              I agree with just about everything you wrote, but there *is* a generic ArrayList in .NET 2.0 - it's just called List, and sits in the System.Collections.Generic namespace. I use it all the time, along with the generic Dictionary class that replaces Hashtable from previous frameworks. Generics are truly great, but I'm an old C++ guy so I knew they would be :-)
            • I suspect you are slightly confusing C# and the .NET class library... but your analysis of data binding, resource files and events/delegates is spot on. I'm glad I'm not the only one who feels this way.
            • I agree with all those points, including the hurdles in getting resources going such as icons - could be lot easier. Also, talking to legacy stuff via COM interop is really well done. As has been mentioned it takes almost no effort to do it. Building forms and dialogs is real easy and the IDE remarkably stable. I got sick of doing all the plumbing and myriad datatypes for COM in C++ but I can really get some work done in C#!

            • Re: (Score:3, Interesting)

              by ssyladin ( 458003 )
              I'll admit I've primarily (98%+) worked with Microsoft technologies, including .Net 2.0, so I won't compare what it has to different languages, but I want to make some counter-points.

              # 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

    • Why was this moderated insightful instead of funny?

  • Try this one out (Score:4, Interesting)

    by El Cubano ( 631386 ) on Saturday November 25, 2006 @05:10PM (#16986526)

    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)

      by lkeagle ( 519176 )
      Here's some great books that have nothing to do with the actual programming of GUIs, but are invaluable when it comes to designing them well. Most problems programmers have with programming user interfaces will disappear once you have a firm grasp of how you want your data to be displayed in the first place.

      "User Interface Design for Programmers" - Joel Spolsky

      "The Design of Everyday Things" - Donald Norman
  • 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"

    • Re: (Score:3, Funny)

      by marcello_dl ( 667940 )
      After the input string put a comma not a semicolon, noob.
      • Who are you calling a n00b?
        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.

        • LiquidCoooled (634315), on Saturday November 25, 4:48PM, wrote:

          > 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

      • In Atari BASIC the comma would spit out a tab while the semicolon just concatenated. I think most BASICs were like this.

    • Re: (Score:1)

      by Tablizer ( 95088 )
      Aren't you forgetting?:

      90 PRINT "PROFIT!"

  • I'd be surprised if there was a guide (Score:5, Interesting)

    by Jerf ( 17166 ) on Saturday November 25, 2006 @05:37PM (#16986726) Journal
    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 [hacknot.info], 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.

    • Re:I'd be surprised if there was a guide (Score:4, Interesting)

      by Osty ( 16825 ) on Saturday November 25, 2006 @06:13PM (#16987028)

      even though GUI builders are evil [hacknot.info]

      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)

        by computational super ( 740265 )
        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!"

        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:1)

      by gknoy ( 899301 )
      You mentioned Ruby. Do you have any suggestions for a good toolkit to use with Ruby, and any good sample / example / tutorial code/info on using said toolkit? I've looked briefly at the FXRuby toolkit (Based on the FOX toolkit), but wasn't sure if there were any other good kits out there.

      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. ;) I'm a relative Ruby neophyte, so that may be part of my slacking's reason.

    • Re: (Score:3, Insightful)

      by ClosedSource ( 238333 )
      "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.
      • The whole point of using a tool that generates boilerplate code

        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)

      by peterarm ( 95041 )
      One thing that is special about GUIs is that it's much harder to unit test them. Yes, you can build an object model and unit test that, but it's not as ideal a situation as what server side developers can do. If you don't have a comprehensive suite of tests, it makes refactoring much harder. Server side developers are spoiled in this regard (building good unit tests is much easier), but many don't realize it...

    • Re:I'd be surprised if there was a guide (Score:4, Informative)

      by Bazouel ( 105242 ) on Sunday November 26, 2006 @01:32AM (#16989814)
      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!
      • I mean, has he ever heard of UserControls? Of MasterPages/Forms? What about using a single DropDownList instead of multiple RadioButton?

        Here you see what happens when people do too much GuiDesign.

      • ``If one know how to use a modern GUI toolkit correctly, then his whole point on code reuse/repetition disappear.''

        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
      • What about using a single DropDownList instead of multiple RadioButton?

        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)

          by Bazouel ( 105242 )
          Using dropdown lists is actually a *mandatory* accessibility guideline when designing a web interface. Yes, even for Yes/No choices. If you don't do it, you will fail the validator. See http://www.access-board.gov/sec508/guide/1194.22. h tm [access-board.gov]

          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.

  • The basics. (Score:5, Interesting)

    by Balinares ( 316703 ) on Saturday November 25, 2006 @05:37PM (#16986728)
    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.

    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. :) Hopefully other people will have more details to give you.

    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)

      by McLoud ( 92118 )
      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
      See? That's why you dont use these evil MVC-oriented programs, one just ate your post.
    • I'd also recommend looking at the factory pattern. Whenever you need a form/page/screen, you just instantiate the appropriate factory and have it create the form/page/screen. The factory will know what widget set you're using, what OS you're targeting, and what device the GUI should work on. Typically you'll make a generic GUI factory, then subclass it for the particular widget set you're using.

      Try to design your GUI so that it can assemble itself (via a layout manager or templating system). This makes
    • I second the suggestion to look at Model-View-Controller. It is not always clear how code should be separated to fit the pattern, and it's not always possible or desirable to separate the three parts to the point where each part could be modularly swapped out. But maintaining a healthy amount of separation, especially between the model and the view, will definitely result in a more flexible and easier to maintain application.
  • You want code re-use?
    Object oriented design techniques work equally well for all areas of software engineering. Don't think there is some "special" technique for GUIs.
  • There are all kinds of User Interfaces out there, and the simple elements such as buttons and boxes are popular mostly because they constitute the huge majority of "conventional" expectations. Tcl/Tk will give your a little more control over offbeat interactive elements, and early game books for C/C++ programmers will give you even more. What you learn from a book like Charles Petzold's, "Windows Programming" 5th Ed. will give you even more control over what happens on the screen. Petzold wrote some great b

    • Re: (Score:1)

      by Amadodd ( 620353 )
      Accpac for DOS had a DOS report writer called Caret, which I believe was the forerunner of Crystal Reports or just had similar features. Back in the day it had pretty amazing capabilities.

  • 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 navigatio

    • Re: (Score:3, Interesting)

      by Anonymous Coward
      And please, PLEASE, when possible, use the colours that are specified in the gtk/qt/windows theme settings.

      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
      • Don't hit me too hard for this one... since I'm stuck on Windows at the moment, I might as well mention that the 'Made for Windows $version' logo testing requires using Windows supplied colors. It's part of the accessibility requirements for instances where the user needs a high-contrast color scheme (iirc).

        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)

      by Tablizer ( 95088 )
      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.

      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)

    by Tablizer ( 95088 ) on Saturday November 25, 2006 @08:21PM (#16987954) Journal
    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).
       

    • Re: (Score:2)

      by mrlpz ( 605212 )
      What the flog are you talking about ? Near-pinnacle ? That's exactly the neanderthal response I would expect from a VB/Delphi programmer ( emphasis ON PROGRAMMER ).

      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)

        by Shados ( 741919 )
        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 k

        • Re: (Score:3, Insightful)

          by ClosedSource ( 238333 )
          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.

        • Re: (Score:2)

          by mrlpz ( 605212 )
          Oracle Developer was a customized build of JBuilder tailored to work specifically and singlely with Oracle 9 ( and subsequently 10 ). I know, because I used those two products.

          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)

            by Shados ( 741919 )
            Those are IDEs that have some RAD capabilities. Not at all the same thing as eDeveloper, Oracle Developer, VB6 and so on.

            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)

              by mrlpz ( 605212 )
              what the h_ll are you talking about then, because JBuilder ( and it's derivatives ) are classifiable ( even Oracles' literature classified them ) as RAD environments. Clarify your statements there, eh ?

      • Re: (Score:1)

        by Tablizer ( 95088 )
        You were not specific. Show me something that VB/Delphi cannot specificly do. Also note that internal applications and "boxed" mass market apps are two different things such that I don't necessarily claim that VB/Delphi is best for those. I am considering only inhouse or narrowly-distributed apps, not mass-market.

        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'
      • The remark about the evil of ActiveX controls is sort of like remarks that since people in occult cults listen to rock-and-roll music then people who listen to rock-and-roll are susceptile to occult cults or belong to them (or some variation thereof).

        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)

          by mrlpz ( 605212 )
          No one said they weren't powerful or useful, but your assertion that the Type Library Editor included in Delphi ( and C++ Builder for those who've used it ) has it's own issues, many of which have never been addressed by Borland. For a user of anything remotely related to IDL the Delphi tools are no better than the VC++ tools, it simply boils down to a matter of taste.

          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
          • I am not sure which defensive position I am taking -- defending ActiveX or defending Delphi.

            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)

      by Shados ( 741919 )
      .NET/Visual Studio has better GUI "drag and drop" support than VB6 ever did.

      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)

        by Tablizer ( 95088 )
        .NET/Visual Studio has better GUI "drag and drop" support than VB6 ever did.

        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.
               
  • It sounds as if you are looking for tricks to make GUI programming easier rather than software engineering practices to build GUI interfaces. It's my opinion that as you program you can come up with your own methods to do that; however, you might want to check out the book "Professional Java user Interfaces" by Mauro Marinilli, Wiley Publishing. It doesn't seem to have many tricks, but does seem to focus on the software engineering aspect of GUI programming.

    Make sure to look thro

    • Re: (Score:2)

      by mrlpz ( 605212 )
      Personally ( and I'm COMPLETELY serious about what I'm about to say ), I keep a copy of "GUI Bloopers" on my desk. Not so much as a reference guide ( which it is ), but as something solid and blunt to BONK any usability person who comes up draconian ideas of user interface design. Allow me to synthesize a lemma based on one of Einsteins postulates: The user interface should be as stupid as the user, but no stupider.
  • As a software engineer turned UI designer, it seems to me that when the UI gets re-done, it is either trivial (change this word, so you change a properties file), or a complete overhaul. UI layers don't get maintenance the same way other layers do. Lots of people see them, so they change dramatically when there are problems.

    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)

    by itomato ( 91092 ) on Saturday November 25, 2006 @11:21PM (#16989158)
    Some resources:
    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.
  • I'd like to know what kind of repetition you are seeing. Some of the posts here point out you will need controllers that are specific to your application. If you are seeing repetition there, then it may be an issue of wanting to reactor the UI itself and not the code. If you are copying the same draw(getIcon(MY_COOL_ICON)) then maybe you do need to subclass some pane to hold your icon. Also, at this point, most GUIs can be built nicely with the GUI Editors. Naturally you can make your UI better if you put

  • And for chrissakes, remember this is a HMI (Score:3, Insightful)

    by thoglette ( 74419 ) on Sunday November 26, 2006 @01:30AM (#16989802)
    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: (Score:2)

      by RobinH ( 124750 )
      If you're getting into the kind of issues you mention, I highly recommend the book, "The Design of Everyday Things" [amazon.com] by Donald Norman. He uses simple examples like door knobs, stove tops, etc., but all of his work is directly applicable to GUI design. The principles of good design are timeless.

  • Threads and GUI (Score:2, Informative)

    by DimGeo ( 694000 )
    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.
  • Ive come across this problem many times over the years. I can give you some advice in Windows, which is where I have the most experience: To reuse UI code easily, use a library that exposes the Win32 GUI API as a class hierarchy, like MFC. You can derive from classes to specialize a control, and reuse the base class handlers and such. To reuse the UI itelf, use a "sub-control", to do that easily in windows create a dialog without caption, put the controls you want in the dialog, and in properties make sur

  • A good article to start (Score:3, Informative)

    by neves ( 324086 ) on Sunday November 26, 2006 @09:30AM (#16991190) Homepage
    I wholeheartedly recommend this Martin Fowler's article [martinfowler.com] to start with.

  • 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!

    • I'd agree. Designing a good GUI is not something many developers do well. Most developers develop GUI's that they think are good, but often lack in many ways, usability often being the first.

      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

  • This looks really interesting: Adam and Eve [adobe.com]
    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.
  • I'm not sure what you're doing in your gui, but here's my own $.02. (Note: this is Java related more than anything else, though my thoughts could be extended to C# I'm sure)

    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,
    • I agree with this statement. I would add other things as well. Java like to be very flexible, putting listeners, bars, and buttons as seperate items. You reall don't need all that flexibility. If you REALLY want to reuse code and simplify your life, try making a single object that incorporates all three things. It is not that hard to have method on your bar type object auto-create a button and and a listener, and require you to implement an action for what happens when you click the button. With a lin
  • You could do a lot worse than to check out SWT / JFace / Eclipse RCP Framework.

    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
  • I would highly recommend that you try and use the VCL (Visual Component Library) components which comes with Delphi and C++Builder. C++ Builder or the Delphi Turbo tools are now available free (the professional versions costs money though - approx $340).

    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)

    by RAMMS+EIN ( 578166 ) on Monday November 27, 2006 @06:50AM (#16999708) Homepage Journal
    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.

  • Nesting and Abstraction (Score:4, Informative)

    by RAMMS+EIN ( 578166 ) on Monday November 27, 2006 @09:41AM (#17000588) Homepage Journal
    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 [gnome.org] builders [microsoft.com] I had used [qnx.com], and certainly beat coding [sun.com] GUIs [gtk.org] by hand [winprog.org].

    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...

Slashdot Top Deals

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Close