Re: GUI Toolkit for Win32

On 4 Jan '06, at 10:32 AM, David Given wrote:

I'm afraid #4 directly contradicts all your other requirements

Not quite; he didn't require that it would be easy to implement :)

--- not only

will you need to implement a huge interface layer between Lua and the

horrific Windows API in order to access the native controls, but in order to

allow the ability to customise those controls from Lua, you'll need to

implement a *much bigger* and even more horrific interface layer to the GDI,

as well as lots of call outs/call ins from Lua to Win32 and vice versa!

This is essentially how Java's old AWT framework was implemented. I was once tech-lead for Apple's implementation of AWT for Mac OS 9 and OS X, so I have some experience with this; and yeah, it's a huge job. Some of the worst parts aren't even the obvious ones: event flow can be a mess, for instance, since the way the underlying OS dispatches events probably doesn't match the way your framework does, and wiring those together can be nasty.

Your best bet, I'm afraid, is either to ditch requirement #4 and draw the
stuff yourself (which will still require bindings for GDI)

…which is essentially how Java's somewhat-less-old Swing framework works. This approach also has major problems,:

1. You have to re-implement all of the appearance and behavior of the native controls.

2. If the OS allows theming or customization of controls, you have to somehow detect and support that too, otherwise your framework's UI won't match that of "real" applications.

3. Transitions between native and interpreted code are quite expensive. The more there are, the slower things get. This can really become noticeable if every drawing operation involves at least one pair of transitions. We ended up having to implement a graphics pipeline to batch as many graphics operations together as possible. (The overhead includes not just the basic parameter marshaling, but a also higher-level issues such as transforming coordinate systems, changing strings to different representations, etc.)

As a result of my experiences, I gave up on the alluring idea of writing GUI applications in interpreted languages. You sacrifice too much in performance, footprint and look-and-feel. Fortunately, about the time I realized this, OS X was finished and I could start writing apps in Objective-C with the nice Cocoa frameworks :) IMHO, interpreted languages are best suited to servers, web apps, and custom one-off apps where ease of development trumps app performance.

--Jens