Towards a native windows GUI

[Ulf Wiger (AL/EAB)]

Joe Armstrong wrote:
>
>     The historical development of GUI programs seems to me to 
> be like this:
> 
> 	1) There were no GUIs
> 	2) Some very simple 2-D graphics API's emerged
> 	3) Simple GUI's with window, mice, keyboard, etc emerged.
>  	4) Complex libraries to make programming type 3 GUIs emerged
> 	5) The libraries became so complicated that nobody 
>        could understand them an so IDE's and GUI designing
>        programs were invented, that spat out code containing
>        library calls for the complex libraries in 4)

I think there are two separate issues with item number 5 above:

- GUI builders actually speed up GUI development dramatically,
  regardless of underlying programming model. The trial and 
  error approach to designing a GUI by trying to write down
  pixel values in a program, running it and observing the 
  results is extremely tedious, esp. if you want to create 
  a professional-looking GUI. It is a _huge_ improvement to 
  be able to draw the window as you want it to look, and having
  the "drawing program" translate that to widget calls.

- The programming model is a different matter. I think that 
  ideally, a GUI builder should translate your drawing to 
  something that you could have written easily enough by
  hand, if it hadn't been for the tedium of figuring out all
  the pixel values and colour codes. The large volume of  
  functions available to control the behaviour of your 
  GUI comes (IMHO) from the mistake of leaving e.g. a 
  pure message passing model, which would be composable,
  in favour of a middleware library approach that isn't.
  This causes the complexity explosion that, as I understand
  it, you're trying to get away from.

/Uffe