On GUI Development

October 1st, 2004 § 12 comments

A reader proposed me the following question:

You are a newbie Windows programmer, although you have a lot of a general programming experience. You want to develop simple Windows GUI applications that will run on Windows 2000 or XP. What would you do? It seems to me that there is no really simple answer.

That’s a really hard question. GUI development is fundamentally different from server development, and there are a lot of things to consider when you decide to go down this path. As he himself pointed out, there seems to be no easy answer.

As I thought about the issue, it occurred to me that all desktop environments on all operating systems I’ve used share those problems. In fact, development for some environments like Linux is even harder than developing for Windows because those environments have more complex GUI architectures, which are flexible and powerful but also lack standardization.

I believe there are two aspects in this issue: first, the development environment itself, that is, the IDE and/or the language and supporting tools in which the program will be written; and second, the toolkit that will be used to interface with the platform’s native GUI or that will emulate it.

Most of the times, those two aspects need to be considered simultaneously because what you choose to solve one of them will limit the choices you have for solving the other. For example, if you decide to develop for Win32 with Borland’s Delphi, you are limited to Borland’s VCL toolkit. (There’s also CLX but it’s not half as useful and mature as the VCL.) On the other hand, if you choose to develop using Python, will are free to pick among a dozen of competing toolkits, each with their relative merits and drawbacks.

Regardless of languages and environments, however, there are some core criteria that must be considered when choosing a new toolkit for GUI development. Some of them are:

  • Speed of development
  • Run-time performance
  • Visual identity
  • Easy of deployment
  • Extensibility
  • Portability
  • Documentation

Speed of development is certainly the most important criterion when choosing a new toolkit. Interesting enough, when you discount the effect of the language used, you realize that, in most mature environments, speed of development is a direct function of the simplicity, power and flexibility of the environment’s supporting libraries. Experienced programmers can acquire a new language with whose paradigm they are already acquainted with in much less time than they will take to truly absorb all the APIs provided by the language and its supporting tools.

Productivity when developing GUI application then becomes a matter of how well the GUI libraries support the underlying platform widgets (simplicity), how well a common API is presented to those widgets (simplicity), how far they let programmers go (power), and how easily they can be integrate and extended (flexibility).

Unfortunately, most toolkits in wide use today fail where simplicity is concerned. Visual Basic succeeded not because it had a visual development environment, but because it made really simple to understand what was going on behind the scenes. Programmers could understand what was happening and devise simple solutions for their problems. The same was true for Borland’s Delphi. The ability to visually create a form and put components on it, linking their events together was secondary to the ability to quickly go beyond that to more advanced programming models. I’ve seen many Delphi applications based on MVC concepts where the GUI was created programmatically and whose programmers were an order of magnitude more productive than those who edited their forms visually.

Many visual environments exist only to hide the complexity of the underlying libraries. Programmers who grow used to this kind of environment will have trouble if they need to extend the environment for more complex tasks. After all, programming GUI applications is not just a matter of laying out components on a form and creating code to respond to user-generated events.

Run-time performance is also an important criterion. One of the causes of Java’s failure to gain the desktop was its abysmal performance in the AWT era. Of course, the virtual machine was not as well developed then and that contributed for the failure as well. Swing today is much better, but its performance is still not good enough, especially when garbage collection kicks in.

Most GUI toolkits avoid performance bottlenecks becoming just thin wrappers around the features provided by the underlying operating system, which is also the common way to meet many of the criteria mentioned above.

The most essential aspect of run-time performance, however, is related to extensibility. The path to extensibility must not harm performance. If a programmers needs to develop a new visual component, that component must perform as well as the components native to the toolkit — provided, of course, that it was correctly written. That’s a big problem for toolkits whose main components are wrappers to the operating system widgets but that require programmers to painstakingly draw the components they create in a generic canvas and process all events they wish to capture, incurring in huge performance penalties

Visual identity, that is, the toolkit’s ability to blend with the operating system under which the application is running, is an interesting issue. As long as applications developed with a given toolkit are able to smoothly integrate into the working flow of the host operating system, acting as users expect them to act, rather large cosmetic differences will be ignored. Users expect consistence. Users will not mind if buttons are larger in one application than in another. But they will mind if each application defines a different keyboard binding.

Easy of deployment is obviously essential because no matter how fast you can develop an application, if you can’t get it to your users you are doomed. But as long as the deployment process is transparent, users will not mind it. Applications can run standalone or require virtual machines and run-time environments, but users will not care until they are forced to take actions other than click the Next button in an installation wizard.

Extensibility is also critical because more than often programmers will need to create additional components not considered for the original libraries. Unless the original library can be easily and seamlessly extended, it won’t provide much value for programmers.

Portability is only important if the users are distributed across heterogeneous platforms. Nonetheless, I included it because I think portable toolkits tend to be simpler and more powerful than native toolkits because they need to cope with different environments and the idiosyncrasies of those environments. As a result they are more well thought and more flexible.

Documentation may be one of the most vital aspects when considering a new toolkit, especially if the libraries provided by the toolkit are big. Without documentation, programmers will be hard pressed to understand the fine points of programming against a given toolkit, mainly because there are no toolkits who provide the same API or behave the same way. Even ports of the same toolkit for different languages hide the toolkit’s complexity in diverse ways so that the mindset for using that toolkit can vary with the language itself.

Once we consider all those criteria, we find that most GUI development toolkits in the market today fail to meet many of them. Especially where speed of development is concerned, most toolkits provide too complex interfaces that force programmers to learn a lot of peripheral details about the toolkit’s workings just to code very trivial applications.

C/C++ toolkits like Qt, Gtk and wxWidgets require programmers to understand a mishmash of functions, objects, macros, and include files before they can even start thinking about the application’s logic. They don’t hide complexity. Programmers need to think about signals and slots rather than application flow — models, views, and controllers. Even when those toolkits are ported to other languages that support more productive constructs — like Python, for example — they tend to preserve the needless complexity, instead of making use of the language’s features to create a better API.

I think one of the few toolkits available in the market today that meets most of the criteria aforementioned is Borland’s VCL, shipped with Delphi and C++ Builder. Except for portability across operating systems, the VCL has all other characteristics described above. Although Borland never attained more than a small share of the development tools market, the VCL was so successful within its niche that it inspired a lot of other toolkits like Microsoft’s Windows Forms for .NET (created by one of the guys who helped to build the VCL) and Sun’s Swing for Java. VCL was successful because it was simple to use and extremely extensible. Programmers could create new components based on existing components or from the scratch in a very easy way. And those components could be completely integrated in the existing development environment. They were identical to the components native to the library. Also, if a programmer found a bug in a given component provided by Borland, it was often just a matter of creating a new component that inherited from the bugged one and overrode the offending method to get the application working again. There are still hundreds of thousands of components available in the Internet for Delphi just because the toolkit was flexible enough. Yet, even though it was simple and powerful, it still took a lot of time to understand all the libraries that made up the VCL, and how they interacted.

To finally answer the question posed by my reader, I have to agree with him. There is no silver bullet. Regardless of the toolkit you choose, there will be a lot to learn in order to become proficient with it. And that knowledge will likely be worthless when the time comes to learn another toolkit.

Some toolkits boast about the fact that you can create complete application without writing a line of code. Therein lies evil. That’s a PowerBuilder mentality. You can indeed create applications that require no lines of code. But they will probably be simple data entry applications that can’t be extended and that break whenever a programmers needs to create a more complex business rule. The only successful application in that regard that I know about is Squeak, and that’ s when it’s used as an educational tool.

That said, I believe there are quite a few toolkits that are worthy learning if you intend to develop professional applications. Most of them have serious problems in one or another of the characteristics discussed above, but they all are interesting and productive enough to be a valuable additional to any programmer’s arsenal of tools.

Borland’s VCL, which can be found for free in Delphi Personal, is worthy a try, although it will likely disappear in a near future. Borland is phasing out pure Win32 development in favor of .NET, and newer Delphi versions sport a new toolkit, VCL for .NET, which is a wrapper around Windows Forms. But it’s a good example of what a good toolkit is, and it’s nice to work with.

Windows Forms is also worthy learning. The .NET redistributable is free, there’s a entry level version of Visual Studio for free, and there are some interesting open source development environments. Windows Forms and the VCL are very similar, but they have some interesting differences that merit a look. And it’s the future for Windows as well — or so it’s said.

Another interesting toolkit is wxPython. It’s a port of wxWidgets, but is slightly modified for a Python feel. There’s even an IDE for it, although was still a bit flaky last time I looked. The most interesting things about wxPython are its portability — it’s available in more platforms than you will likely need to support — and the fact that, being based on wxWidgets, it’s pretty solid.

VisualWorks, one of the leading Smalltalk implementations also features a flexible and powerful GUI toolkit. In fact, Smalltalk and GUI development have common roots, with the same visionary as their pioneer. VisualWorks’ toolkit is a bit complex, but its Smalltalk MVC inheritance makes it very powerful. JPMorgan recently chose (PDF, 1MB) VisualWorks for its Kapital risk management and pricing system. They estimated they cut their costs and development time by three because they choose a Smalltalk-base solution.

Were I to choose a development environment today for Windows or Linux, I’d probably pick wxPython (or any other port of it for the project’s chosen language). wxWidgets is not much more complex than the other toolkits; it has the native look and fell of the platforms it runs on; it’s mature (development on it started in 1992); it’s well supported; and it’s also free. Additionally, it has a lot of things built in, like a configuration manager and support for printing, OpenGL, HTML, networking, and Unicode. There are many supporting tools to choose from, including a GUI builder. Other non-trivial tasks, like database access, would depend on the programming language used. Python, for example, has good database support.

Although those toolkits are dissimilar, they offer a broad range of features that will greatly aid programmers in their tasks. There may be no simple answer, but I believe there are good enough answers for the problem stated.

§ 12 Responses to On GUI Development"

  • Clint says:

    Thanks for the detailed response to your reader’s question ;-) I’ve come to the same conclusion (winGlade, wxWidgets). Actually, my favorite approach right now is the Bloodshed IDE with winGlade. The big problem I’m having now is finding the best way to integrate these tools and make sure I’ve got the latest versions. I too am looking at Guru Kathiresan’s wx-devcpp (http://wxdsgn.sourceforge.net/), but it doesn’t seem like it is a very active project. — Clint

  • Clint says:

    Or would it be better to just bypass the GUI toolkit idea (i.e., Glade) and just go with a CPP IDE and wxWidgets and manually create GUI elements?

    With all these different options, and no open source solution that is as easy for beginners as Visual Basic (for creating GUI apps for Windows), it’s no wonder most schools teach intro to programming with VB.

    Also, considering all the options, it is probably important to just pick a solution and give a good try. Otherwise you end up with analysis paralysis.

  • Clint says:

    Correction: the wx-devcpp project does indeed look acitve, with beta release 6.2 posted just yesterday (October 1, 2004). See http://wxdsgn.sourceforge.net/.

  • Ronaldo says:

    Both wx-devcpp and Bloodshed’s IDE seem nice tools. I never used any of them because I avoid C/C++ as much as I can, but it would be interesting to try them.

    By the way, if you are taking the wx* route, you should really try Python. You can even generate Windows executables using py2exe, and it’s much cleaner than C++, especially where strings are concerned. :-)

    Also, manually creating the widgets has its advantages. One of them is that you won’t be tied to a specific visual IDE. You can, for example, develop a MVC framework on top of wxWidgets and save a lot of work (if the framework is done right, of course).

    Anyway, as I said, there’s still wxPython and BOA. BOA generates XML description files that you can probably use to generate your our code if BOA stops being maintained, or even port it to another tool if necessary.

  • Anonymous says:

    Borland is _NOT_ phasing out pure Win32 development, they understand that Win32 development will still be required for some time yet. Indeed previews of the next version of delphi show that it contains capabilities to design/compile/debug both Win32 and .NET apps in the same IDE!

    Don’t give up on Borland and Delphi so easily.

  • Ronaldo says:

    I’m aware Galileo will allow both Win32 and .NET development, but I think Borland is not working as actively in Win32 development as it used to be in the past. Delphi 8 was not much more than a bug fixing release, and most of the work went into .NET.

    So judging from what they are doing today, it’s not hard to see that pure Win32 development will slowly give way to .NET development, especially because Microsoft is also going this way.

    But I may be wrong, of course. :-)

  • I think you are wrong about Delphi, version 9 looks like it will be a major step forward for Win32 development as well as .Net. In fact I would say Borland has a good opportunity here with Microsoft’s focus on .Net.

    There are a couple of other things your typical Windows developer needs to consider as well, particularly if they are developing commercial / for download software.

    The first is the size of the runtime, a major problem for ISV’s with .Net is the 23MB runtime download.

    The second is how easy it is to protect their application from decompiling, again a problem with .Net and I suspect py2exe. Any commercial software which doesn’t have a robust wrapper will be cracked within days and this will have an impact on sales.

    Nice article though, Windows developers have a lot of potential paths at the moment.

  • Clint says:

    I don’t know how mainstream it is, but REBOL looks like a really cool Internet OS and language and it is amaziningly simple to create GUI apps.

    Visit http://www.rebol.com to learn more.

    (I’m not affilieated with REBOL, but 10 minutes with it (and that includes downloading and installing) and I’m convinced it’s important!

  • Ronaldo says:

    Hi, Tony–

    Thanks for your comment.

    I used to lurk a lot on the Borland’s newsgroups about one year ago, and I remember a lot of discussions about Delphi’s future. From the direction Borland was taking them, it seemed they would focus on .NET, albeit keeping Win32 as a support platform. Since that was one year ago, I guess I’ll have to update my knowledge about it. Have you any pointers about that subject?

    About .NET’s run-time size, I agree. It’s a big problem when you need to distribute the application, especially on bandwidth-limited channels. I think .NET will be used only on controlled environments for a long time, intranets, servers and similar scenarios where it makes more sense.

    With regards to decompilation, depending on the way code is generated, it may or may not be a problem. If the code is strongly optimized, the decompiled source may be hard enough to read to make copying it worthy. And even compiled applications are cracked in a matter of days. Protecting intellectual property probably is the concern of most companies.

  • Ronaldo says:

    Clint,

    I looked at Rebol a couple years ago, thought it was an interesting language, but hadn’t checked it again since then. The Rebol/View framework is indeed interesting. One more thing to play with in my copious free time. :-)

  • Jeff Sparkes says:

    I just want to point out that JP Morgan has been using smalltalk for a long time; just the document about it is new.

  • Ronaldo says:

    Thanks for the clarification, Jeff. I was under the mistaken impression that they had decided to use Smalltalk recently.

What's this?

You are currently reading On GUI Development at Reflective Surface.

meta