Commercial GUI Builder Usage

Alboin · Post by **Alboin** » Thu Apr 10, 2008 6:37 pm

Hey, I've had a thought about GUI builders. (eg. Glade)

GUI builders allow for easy application creation, but I was wondering if such applications are at all maintainable. Take a commercial program, for instance. I've never had any commercial software development experience, and was wondering if GUI builders are actually used in such areas.

Anyone care to provide any insight as to quench my curiosity?
Thanks.

Solar · Post by **Solar** » Fri Apr 11, 2008 6:20 am

I created GUIs using Visual Studio, both under VC++ and VB(A), in commercial environments.

As always, stuff is maintainable if you take care. Factors like having your source code sitting within a binary and thus not being available for easy diff'ing or by-module checkout / checkin (as is the case with VB(A)) weighs much more heavily on maintainability than using GUI builders, IMHO.

binutils · Post by **binutils** » Sat Apr 12, 2008 8:08 am

i second, vc++ 6.0/2005/2008 at work.
http://en.wikipedia.org/wiki/Microsoft_ ... on_Classes

Colonel Kernel · Post by **Colonel Kernel** » Sat Apr 12, 2008 9:13 am

MFC is dreadful... We used to call it FMC where I worked 10 years ago.

Visual Studio has decent visual designers, but the code it generates can be quite unwieldy and it doesn't encourage good separation of concerns.

I'm learning how to use Interface Builder and Xcode now, and how they work is a lot cleaner. Instead of generating boilerplate code, Interface Builder lets you construct a graph of objects whose roles are described by the MVC (Model View Controller) pattern. You can visually connect them together, and when you save your interface, the instances are serialized into a .nib file. When your app loads, it loads the .nib, de-serializes everything in it, and your UI is ready to go.

Any special code you write in Xcode is invoked by messages sent from the objects you set up in Interface Builder. Typically you would write Model and custom Controller classes in Xcode, and hook up pre-defined View and Controller objects in Interface Builder. This keeps the UI and core app logic very separate. In contrast, for Visual Studio you're usually encouraged to sub-class UI objects like "Form", which violates MVC and leads to unnecessary interdependencies.

Here are some interesting blog posts by a .NET developer learning Cocoa/Xcode:

http://dotnetaddict.dotnetdevelopersjou ... oaday1.htm
http://dotnetaddict.dotnetdevelopersjou ... redata.htm
http://dotnetaddict.dotnetdevelopersjou ... /dcacs.htm
http://dotnetaddict.dotnetdevelopersjou ... stures.htm

Alboin · Post by **Alboin** » Sat Apr 12, 2008 11:21 am

Thanks for clearin' that up for me yall.