Handcode GUI or use gui-designer tool [closed]

Question

I would like to hear some opinions on hand coding your GUIs as one typically do when using Java or Qt with C++, vs using a gui-designer tool? Examples of GUI designer tools would be MFC GUI-designer, Qt designer, Interface Builder (Apple).

I used to be a fan of hand coding but from recent experience I have switched. The problem I have seen with hand coding is that it is fairly quick and flexible to write the GUIs but once you need to make a change to a GUI written a long time ago it can be very difficult. Finding the right element in big panel can be difficult.

The second problem is that it makes it far too easy to add a lot of logic in the GUI creation and layout code. I have often had to take over maintenance of GUI code which is really hard to reuse because its behavior is mixed with its appearance and mixing layout and behavior often makes the class very large and difficult to understand.

Using a GUI designer tool force a much clearer separation between appearance and logic in my view.

Corking

Answer 1

I feel strongly that you should use an interface builder instead of hand-coding a GUI. As in the question mentioned it's a much cleaner separation and once something has to be edited it's much easier.

The Qt Designer got this feature to create a class out of a .ui file₁₎, but I think that not using this feature is the best way, as this creates just more coded that shouldn't exist at all. The speed issue of creating the window from a .ui-file is negligible because the window has to be loaded only once.

This is PyQt, but something similar is possible in C++:

class SelectDateDialog(QDialog):
    def __init__(self):
        QDialog.__init__(self)
        uic.loadUi("resources/SelectDate.ui", self)

Essentially this has the same effect as including all your UI-code into the __init__() method, but the UI is almost completely separated from the code.

¹⁾.ui files are XML files that describe a user interface

Cabrilla

Yes this is my preferred approach when using Qt too. Very dynamic UI I will hand code, but I will try to stick to a designer for the rest. Transforming and XML file as the library changes should also be a lot faster than transforming C++ code describing a GUI. – Corking

Answer 2

I would always hand-code the GUI design where there is no standard (or de-facto standard) GUI markup language (as with Java). The reason for this is that I have found that usin a GUI builder design tool will tie you in to using a particular IDE. Over time, the best IDE for GUI design and/or writing code will change and each developer should be free to choose whichever IDE they feel most comfortable with.

Where I work at the moment, we have a lot of legacy GUIs which were written using Netbeans Matisse GUI builder (against my advice at the time :-). These are now almost unmaintainable because all of the developers prefer either IntelliJ IDEA or Eclipse as their IDE. It is not realistsic or workable to have developers fire up Netbeans just to modify GUI layout (people don't keep the Netbeans project definitions in sync etc).

Another point is that the total time writing out GUI layout code is probably only 5% of the total development effort of a given project. Even if it takes you twice as long to write the code yourself, this doesn't translate as much of an overhead in the grand scheme of things. And it's a small price to pay for long-term maintainability.

As long as you are clear about separating out GUI layout logic from business logic, I don't believe anything suffers as a result. No-one here uses GUI builders any more!

Hydroxy

I don't think this is a proper argument against GUI designers in general. It is an argument against how Java IDEs typically do GUI design. The GUI should be stored in some markup language, and created at runtime, so you don't end up with unmaintainable generated code. or do like Qt with uic. – Corking

I completely agree. If Java had an IDE-independent GUI markup (which was either a standard or a de-facto standard) then I would be happy to use it. I still think that with GridBaglayout I could achieve the same results though :-) – Hydroxy

Oh. nice comment and nice thinking :) – Desimone

Answer 3

I do it by hand, it's a lot easier to shuffle things around and re-use panels inside the application (some panels can appear in several places).

Using a designer works when you're in a team the artists are supposed to do the GUI.

Finding the right element in big panel can be difficult.

?? I've never seen that.

Shafer

Say you got a panel with 50+ elements, put into several layers of layout managers, sub widgets, tabs etc. And you need to move an element from one layout manager to another. You never had problems finding the right layout manager? Oh and you didn't code this panel. Somebody else did. – Corking

I@m not saying it's impossible, just unusual (in my experience). Maybe it's because I indent my GUI code to reflect the layout, sometimes the simple things help the most. – Shafer

@Adam It just sounds like bad code to me. – Francenefrances

@JimmyJ Indenting GUI building code to reflect the layout seems like a really good idea. I'll see if I get into the habit of doing that. – Apocrypha

Answer 4

Funny enough it has gone the other way round for me. Talking from Winforms perspective, the code generated by the designer is quite noisy, with maybe a quarter or half of all the property settings really necessary. Making pretty big controls is also more of a temptation when working with a designer. Changing some hierarchy of controls in the Winforms designer is quite a nightmare in my eyes.

In my last project I have created additional APIs to set up splitters in forms, dockmanagers, menus, toolbars etc. in a declarative fashion. These are such that they will further enforce separation of concerns.

I also try to rely much more on auto-layout features which admittedly are a lot nicer in WPF but can also go some way in Windows Forms.

Keratin

I completely agree with your comments about noise generated by using builders. This is also true of Java - one usually ends up with tens of JLabels as fields of your class, whereas they are never really needed. – Hydroxy

I don't think the noise generated by the designer matters as long as you can treat that code as a black box and don't need to edit that by hand in any way. Preferably GUIs should be constructed at runtime by parsing a markup language. E.g. XML like XAML, XUL (firefox), or Qt designer XML. – Corking

Answer 5

I would strongly advice you to use Interface Builder on OS X. Doing it by hand is fine if you want to learn, but you're going to save yourself a lot of headaches by using it on actual projects. It really is quite powerful.

As for Java and C++, it depends on what you're doing and on what platforms. For simple applications you can get away with never seeing the UI code. However, for complicated applications and rich clients, you typically have to do some of the code by hand.

Marinmarina

Answer 6

If you are designing a business application with lots of entry forms and tabular data, writing code for your UI is both faster and more maintainable than using an UI designer. In those kinds of applications, there almost never need to precisely place one element at predefined place on screen, while on the other hand, there is a lots of repetition and design conventions that can simply be extracted into separate methods.

Take for example an Eclipse or OpenOffice preferences dialog. There are a bunch of categories and a bunch of different options to set for each. If you have to make something of that size, hand designing each screen is a mundane task. Much better approach is to write code which will generate UI elements on-the-fly, from provided domain data, according to some conventions and defaults.

I don't see how using a designer facilitates better separation, nor how that perceived separation would help with anything, given that you already keep your business logic out of the UI.

And, finally, if you're using Java, be sure to check out MigLayout. It works with Swing and SWT, its' syntax is very concise and clear, and it has a debug mode that's unbelievably useful.

Duple

I agree that for very dynamic GUIs, e.g. ones that can be generated from model data, then hand coding is better. However I think that is a special case. – Corking

Depends on the niche you're working in, I guess. Majority of UIs that I write are much better suited for hand coding: rows and rows of trading and payments data, different kinds of options for reporting, adding/changing options often etc. – Duple

Answer 7

It depends on the situation, really. I think both have their place, and I usually use a hybrid approach.

There are always some things that the GUI builder can't do (for example setting the color to a UIColor constant in Interface Builder). On the other hand, most of UI work is pretty mundane (for example adding static labels).

I prefer to do the mundane stuff in the GUI builder, and the more interesting stuff in code.

Also, I occasionally find myself editing the XML produced by the GUI builder (Interface Builder and glade in my case) by hand.

Semidiurnal

I think GUIs should be defined in something easily readable like XML so you can change it by hand if you need to. The benefit of XML compared to e.g. C++ code is that it can be easily parse back by the designer. – Corking

Answer 8

I tend to think the right answer depends on the culture of the target platform. On OS X, Interface Builder is such an integral part of the tool chain that it's difficult to avoid it.

In Java (awt or swing), the reverse is really true. There is no toolchain support for this.

Really, the way you can tell, is the way the tools produce their outputs. Interface Builder produces .nib format files which are specific to the way Cocoa puts controls on the screen. It understands what is essentially an interface markup format. Java has no such similar concept. Everything is a compiled class, and therefor its much more difficult to get convenient results.

GTK+, when combined with glade, seems to strike a reasonable balance between the two.

Steersman

Answer 9

Nothing prevents from mixing the two approaches. I often make the main layout of a form in a GUI designer (because it's quick and you see what you're doing), and put there one or more panels which are then populated with code. This is especially useful when the GUI must adapt to specific situations - for instance, if the GUI must change according to what hardware is connected.

In any case, the most important thing is indeed to keep GUI and application logic separate.

Intermediate

Answer 10

My view on this: 1. Hand-coded GUI code is much more reusable 2. Layout issues are simpler with designers

Terror

Answer 11

Hand coding can be good if you want some non-standard features included in you UI. You have more flexibility, but you will need to invest more time to create a good interface, because Java/C++ are language not mean to target UI design.

On the plus if you have a revision control you can look at the history of changes, something that can't be done with a designed that uses a binary format, or an xml format which is not RCS friendly.

Today most of the available tools to visually design an UI have missing some features. They are not flexible enough, some features can only be attained coding them. Also in some cases the generated code is not really human friendly, and if you modify by hand you may no longer be able to continue using the designer.

But the designed can be really a time saver if the design is simple, and we can hope designers will be improved in the future, but I will not hold by breadth.

My conclusion is if you need flexibility today you will have to code by hand the interface, if you want something simple and fast then designer is the best choice.

Perhaps in the future the designers will be more powerful, or perhaps there will be new languages specialized in the UI design which will be more suitable for use in C++/Java, something like XUL or XAML.

Tracy