Do you code a GUI or design it?

[Ecaz]

Ok, so I'm not having a problem but I didn't know where else to place this question.

I'm just now "re-learning" C++, I never got into GUI programming before and it's been almost 4 years since I last touched this language.

Anyways, my question is simply, do you code a GUI or do you design it?
What I mean by this is, there are a lot of tools out there with a nice design view of what you're doing. You can drag and drop buttons onto a window, you can drag and drop a browserController and a bunch of other things.

There is still coding behind all of this, to make it work the way you want it, but do people code their own GUI as in they write code to create a new window, they write code to place a button in this window and on this position. Or do they use one of these design view thingies. Like Visual Studio and the QT Creator?

And when I say people I mean the general professional development. Programs like Netbeans, Eclipse, Chrome, Firefox etc etc.

The same with games, obviously they code the actions for the user and whatnot but do they have a program where they can place npcs, buildings etc or is it all done in code?

[Labdabeta]

I only recently learned to use GUIs but for the most part I think that it is a complomise. I use photoshop to create my images/textures then load them into my program. For 2d programs I usually draw out my view by hand to try to find out where to place the desired graphical elements. I still have issues designing 3d worlds (although I hear Autodesk Maya is THE tool for it?). From what I have learnt from others it seems that the more your code and your design work together, the better your final project will be. Leaning too far to either of them creates issues. For example, leaning too far to the code side tends to create substandard visuals, leaning too far towards design leads to substandard mechanics. You need both, and lots of both. If you have issues making images, or placing them, try asking a visual arts student (if you can bear it) or at least look up some of the principle theories on visual art and image composition. Realize that just as every frame in a movie should follow the rules of image composition, so should any screen capture of your program, but not at the price of usability and smoothness. Short answer: You really should code and design GUIs. If you use a tool to design it I would suggest trying to find the exact coordinates of everything so that you can put it into the code from the design area.

[mike_2000_17]

I guess I agree with Labdabeta.

It's a matter of balance. There are things that you need to code, and there are things that would be really stupid to do via code.

The reason why drag-drop GUI designers exist is because it is really asinine to do all that in the form of code. For example, if I'm creating a notepad application, I need the edit area to be resized every time the window is resized, i.e., it should fill the window. I could code this up via an "OnResize" event with code to update the size and placement of the edit area within the resized window area. But doing this would be a waste of time, if all I need to do is check a checkbox in a GUI designer to tell it that I want that component to expand along with its parent window. And then, I won't even talk about how wasteful it would be to actually have huge lengths of code that just place components at the right place and resize and all that stuff. Doing all that stuff via code is like creating a 3D model with lots of code that creates the mesh with hard-coded points. When you think of it that way, and know how stupid it would be to create your 3D models like that, you realize why drag-drop GUI designers are good and what they should be used for.

And then, of course, you have stuff you need to do with pure code, i.e., commonly referred to as the "back-end". And very often, actually, the back-end is a separate set of small programs, especially in Unix-like traditions, which is generally useful because the GUI can change at a whim, but the back-end code is generally much more complex and kept long-term.

So, the tricky part is about where the drag-drop designing stops and where the coding starts.

In my experience, you cannot create any kind of non-trivial GUI without good software design under-the-hood. That doesn't mean you necessarily do more coding than GUI designing, but it means that you must design your GUI by thinking about the way you're going to deal with it (its components) in the code, and also by understanding the limitations of those drag-drop designers.

One of the problems with drag-drop designers is that they are biased towards generating very monolithic code under-the-hood. What I mean is that it is easy to start with a window and start adding stuff to it, menus, edit boxes, panels, check-boxes, and so on, leaving the necessary coding as an after-thought, and when you do get to the code, you end up writing one big "Form" class with a gizillion event callbacks that each have to do a gizillion things (e.g., disabling some check-boxes, updating some combo-boxes or list-views, and so on) and deal with all possible "states" in which you might be. In other words, you end up with monolithic spaghetti-code under the hood. It's important to be aware of this so that you can avoid being sucked into that sink-hole.

Ironically enough, another thing that drag-drop designers are usually terrible at is allowing you to create modular GUIs. They give you the illusion of modularity by their very nature (i.e., adding modules or "widgets" to a GUI), but there is a difference between creating your GUI as modular parts and using modular components provided to you. The latter is the hallmark of GUI tools, but the former is something that you must do, and the GUI tools are not always facilitating that process. Qt is very good in this department, others not as much, as far as my experience with them goes. In a nutshell, you should think about your GUI in the same way you think about an OOP-style software architecture, and force your GUI tool to allow you to write the modular parts you need. One task equals one widget, not one application equals one window.

And finally, you can't forget about good programming practices just because you aren't writing code. You want to avoid hard-coded values, e.g., hard-coded sizes should be replaced with automatic layouts. Minimize repetition, i.e., if you see a pattern being repeated (just like in code), you should think about making it into a separate module and inserting it multiple times instead. Use meaningful names for variables and objects, i.e., avoid the insanity of default names like "Box1", "Box2", "Box3", "Box4".... ad nauseam. Be savvy about managing the files, i.e., source files, headers, GUI definition files, MOC-ed files, generated binaries, images, resource files, etc.... since you should always be using version control, you generally need to be keeping things well sorted out (out-of-source builds, moc'ing, and resources). And so on.

In other words, think of the drag-drop interface as a visual programming tool, you're still coding, but instead of typing, you're pointing and clicking. For example, I did quite a bit of programming in LabVIEW in the past, this is a (semi-)general programming language entirely based on doing drag-drop-point-click stuff, no typed code at all, but you still have to treat it like you are writing code, and I would say, the same goes for GUI designing. So, I guess my answer to your question "do you code or design a GUI?", I would say, I code it using the drag-drop designer, it's that simple.

And as far as making things look pretty, just tell everyone that you're an artist devoted to minimalism and that you reject the "dépassé" style of flamboyant expressionalism. In other words, keep things simple, and embrace it. It's far less work that way, and it usually turns out being more pleasing to the eye, and practical.

The same with games, obviously they code the actions for the user and whatnot but do they have a program where they can place npcs, buildings etc or is it all done in code?

They certainly have editor programs to create the scenes, scenarios, npcs, etc... and often, these are saved in proprietary file formats. And I wouldn't be so sure about the "obviously they code the actions", very often those rely on high-level scripts too. From what I know, most game programming companies have quite a significant portion of their programming staff dedicated to writing editors so that the artists / game-concept team can use them to create all the game-play logic, the GUIs, the scenes and scenarios. Most of the actual programming that goes into making a game is in squeezing as much visual effects and detail as possible through the limited rendering pipeline, as well as in the artificial intelligence of NPCs and the physical realism of the environment (i.e., the "physics engine"). In other words, all the content (and sometimes part of the logic) comes from files and high-level scripts, and the coding is to ensure a timely, smooth and realistic delivery on the screen. So, again, it mirrors what I said earlier about using the right tool for the right job, there is no point in hard-coding content, whether it is simple logic, component placements or visual art, so, nobody (professional) does that.

[Ecaz]

I don't think I could have asked for a better answer!

I'm mostly work with web so GUI coding is fairly new to me. And I just thought it was "cheap" to use GUI designers. In my mind it was like using Weebly or something similar. Where you just drag and drop premade elements and then your website is finished, everyone can do that.

So initially I thought it took away the "skill" of coding.