Towards a native windows GUI

[Serge Aleynikov]

Hi Joe,

While having an ability to do GUI programming in Erlang the way you 
described is definitely useful (noting the challenges mentioned by Mats 
and Vlad), I'd like to bring another point to this discussion.

It looks like the problem can be addressed in two ways:

1. How do we interface Erlang with GUI programming?
2. How do we interface GUI programming with Erlang?

I don't think the two approaches are the same effort.  I think that the 
second one has a value in a sense that if Erlang would offer an API 
(much simplier than erl_interface) that would allow for it to be 
embedded in the OO-realm of component-based development, then we'd give 
a chance to the over-populated OO GUI community to interface with Erlang 
emulator quite easily.  This way the nice-looking GUI programming could 
be done in languages and IDEs that are specifically designed for that 
purpose, and manage the tasks suitable for Erlang from GUI through a 
well-established message passing API.

As far as the first approach is concerned on Win32, I suspect that a 
sub-set of Win API selected for making simplistic GUIs would still be 
large enough to keep it really simplistic.  I just went back to see 
"under the hood" of the Delphi's implementation of the windows message 
handling procedure for the main form of an application, and it has code 
for each of the following messages:

WM_ACTIVATE, WM_SETFOCUS, WM_KILLFOCUS,
CM_SETACTIVECONTROL,CM_EXIT,CM_ENTER,WM_WINDOWPOSCHANGING,
WM_DRAWITEM,WM_MEASUREITEM,CM_WININICHANGE,CM_SYSCOLORCHANGE,
CM_SYSFONTCHANGED,CM_PARENTCOLORCHANGED,CM_PARENTFONTCHANGED,
CM_PARENTBIDIMODECHANGED,WM_SYSCOMMAND,WM_CLOSE,WM_PAINT,
WM_ERASEBKGND,WM_QUERYDRAGICON,WM_SETFOCUS,WM_ACTIVATEAPP,
WM_ENABLE,WM_CTLCOLORMSGBOX,WM_CTLCOLORSTATIC,WM_ENDSESSION,
WM_QUERYENDSESSION,WM_COPYDATA,CM_ACTIONEXECUTE, CM_ACTIONUPDATE,
CM_APPKEYDOWN,CM_APPSYSCOMMAND,CM_ACTIVATE,CM_DEACTIVATE,
CM_ENTER,WM_HELP,CM_INVOKEHELP,CM_WINDOWHOOK,CM_DIALOGHANDLE,
WM_SETTINGCHANGE,WM_FONTCHANGE,WM_THEMECHANGED,WM_NULL

Doable?  Yes.  Simplistic?  Not quite.

Regards,

Serge


Joe Armstrong (AL/EAB) wrote:
> Hi Serge,
> 
>     Let me be clear, What I want to do is *simplify* GUI programming - reduce GUI
> programming to understanding a small number of well-defined primitives.
> 
>     I am well-aware that the Win32 GDI has a large number of procedures (or as David Hopwood say, "thousands") that do mysterious things.
> 
>     What I want to know is "is there a small sub-set of these procedures" that
> I can write a simple GUI with?
> 
>     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)
> 
>     It seems to me that things went wrong at stage 4 - the very fact that you *need*
> a IDE/wizard/whatever to write the code for you seems the underlying structure is
> too complicated.
> 
> 	There is a trade-off involved here:
> 
> 	Suppose I have a very simple library, and programming language, say like this:
> 
> 	Win = mkWin(X, Y, W, H),
> 	Button = Win !! {addButton, X1, Y1, W1, H1},
> 	Button ! {addtext, "Press me"},
> 	Button ! {onClick, fun() -> ... end},
> 
> 	Etc. (like my ex11 :-) - then you can learn the language quickly and produce
> ugly but functional GUIs very quickly, and I can build dynamic GUIS.
> 
>       With GUI builders - the learning curve is steeper, interfacing to Erlang is
> painful, and forget dynamic GUIS.
> 
>       The trade-off is "Easy to program = Ugly GUI" vs. "Difficult to program = Nice GUI".
> 
> 	Suppose we (say) implement an Erlang interface to GTK (there seem to be
> at least 3 of these), then the following problems seem to occur:
> 
> 	a) The interface library won't build in my environment
> 	  (it worked fine on the developers machine but particular combination of
> 	   shared libraries/OS etc. needed differs on my machine)
> 	b) I have to learnt the GTK programming model in order to write a GUI
> 	  (and is that fun? - no)
> 	c) The result is non-portable
> 	   (ie the target machine must have performed a) successfully)
> 
> 	What I'd like to experiment with are simple libraries using only the X protocol
> or the Win32 API - where the programming language is pretty much as above.
> 
> 	I realize that this will not make beautiful GUIS but they will be easy to 
> program and portable. 
> 
> /Joe
> 
> 
> 	
> 	
> 
>     
> 
> 
> 
> 
> 
>>-----Original Message-----
>>From: Serge Aleynikov [mailto:serge@REDACTED]
>>Sent: den 17 augusti 2005 16:57
>>To: Joe Armstrong (AL/EAB)
>>Cc: erlang-questions@REDACTED
>>Subject: Re: Towards a native windows GUI
>>
>>
>>Hi Joe,
>>
>>Joe Armstrong (AL/EAB) wrote:
>>
>>>Programming a GUI as a collection of parallel processes is 
>>
>>very easy. But programming
>>
>>>a GUI as a single sequential process is very difficult.
>>
>>As much as we all like concurrent functional programming, I think it 
>>would be unfair to reject the merit of the modern Windows 
>>OO-based IDE 
>>tools (like Visual Studio .NET, Borland JBuilder, Borland 
>>Delphi, MONO 
>>IDE /that supports multiple platforms/, etc).   Even though they are 
>>based on a single process model, they streamline GUI 
>>development quite a 
>>bit, and given the fact that they are backed up by the key software 
>>monsters, the GUI programming community is quite used to these tools, 
>>and is very productive.
>>
>>Writing GUI in Erlang would also require to have some kind of IDE 
>>(likely also written in Erlang) that would automate creation of GUI 
>>layouts and interactions with widgets.  Without such an IDE GUI 
>>programming would be very tidious and time consuming.
>>
>> From the academic point of view modeling GUI as parallel 
>>processes is 
>>definitely a very interesting excersize, but if that turns 
>>out a viable 
>>solution, would the open-source community build an IDE for it, and be 
>>willing to evolve and support such product (which I imagine 
>>would not be 
>>very simple)?  Would it make Erlang any more popular if it had a GUI 
>>support and IDE?
>>
>>Serge
>>
>>
> 
>