Towards a native windows GUI

[Serge Aleynikov]

Joe,

I tend to agree with Vlad's points as far as not diving too deep in the 
  WinAPI in order to have control of all aspects of GUI presentation. 
Looking years back there have been Windows API SDK and later Microsoft 
Foundation Classes (MFC) that were more than unpleasant to deal with - 
it took several pages of code to write a simple Windows application that 
would merely open a single window.

Fortunately folks at Borland (around 1995) realized that and came up 
with Delphi with its component-based framework, which was quite a relief 
for a Windows programmer, where one could just write:

Button.Caption := 'OK';

and the button object would magically redraw with the right caption. 
Soon VB, MS C++, Java, and later .NET followed the lead.

Each component in these frameworks may or may not have a Window handle, 
and if it does it can receive and act on Windows messages.  The GUI 
Windows applications consist of a message loop, that peeks a message 
from a message queue associated with the main application forms' window 
handle, and dispatches the message by going through all message handlers 
of each control (widget) owned by the form.

The next question is if we want to interface Erlang emulator with the 
Windows GUI, do we want them to share the same message loop for event 
handling?  Probably not - they serve different purposes and I would 
think the priority of the emulator's loop is higher than of the GUI. 
Then the two would be running in separate threads/processes with some 
standard API dealing with message passing.

What tasks would we want to accomplish on the GUI side?  To name a few:

- Use some IDE to create the layout of the application.
- Code handling of some GUI events.
- Make calls to the emulator based on selected user actions.

Does the emulator need to be in control of all of that?  Likely not.

What task would we want to accomplish on the Erlang's side?

- React to messages related to user actions coming from GUI
- Notify GUI of a result of some processing via message passing.
- Implement a solution to some problem domain

It would be too much of a constraint to require a programmer to use a 
specific IDE/language on the GUI side.  Therefore some middleman API 
would have to be developed that would interface with Erlang, and be 
ported into multiple GUI frameworks in a form of a component.  That 
component would allow to send/receive messages to/from Erlang node by 
assigning event handlers, be dropped on a form in design time 
(non-visible at run time), etc.  This approach would also allow a 
programmer to take advantage of the variety of 3rd party GUI libraries 
with nice grids/controls/styles/etc to make applications more spicy.

Thoughts?

Serge


Joe Armstrong (AL/EAB) wrote:
>    Some random thoughts on a windows GUI:
> 
>    About once every second year I get the same crazy thought - why not run
> Erlang on windows - I hack for a bit and then give up and go back to *nix 
> 
>    So I started googeling and found some interesting stuff.
> 
>    I have often toyed with the idea of using the win32 api to do graphics and *not*
> use a library to hide the gory details - but how easy is this. Having made ex11
> which has a raw X11 interface I thought that it might be nice to look at the
> Win32 api.
> 
>    This is what I have learnt so far. (Actually I may be wrong here - so I'd be grateful if a real windows expert could fill me in on the details, and correct my mistakes)
> 
>    I started by reading http://www.winprog.org/tutorial/ 
> 
>    This was very interesting - what I learnt was:
> 
>    A win32 applications is made up from windows. Inside a window you can place several
> "controls" - a control is something like a button, a listbox, and editor, ...
> 
>    Controls *are* windows.
> 
>    You manipulate controls by sending them *messages*
> 	
>    There are two primitives that send Messages
> 
> 	PostMessage and SendMessage
> 
>    PostMessage is asynchronous - SendMessage is like a remote procedure call.
> 
>    It appears that a very large number of the routines in the winapi merely are wrappers
> to SendMessage and PostMessage.
> 
>    Thus interfacing Erlang to the windapi "merely" involves interfacing SendMessage
> and PostMessage and a few small routines like CreateWindowEx.
> 
>    << I think you could get a lot of mileage from just interfacing CreateWindowEx, SendMessage and PostMessage - but this might be incorrect << can a real windows expert comment on this>> >>
> 
>    Next problem - where are the arguments to PostMessage and SendMessage documented?
> 
>    Not in the APIs and you can't read the source - BUT - I did find the following
> 
> 	http://www.autohotkey.com/
> 
>    Has a free program that actually makes windows useful - this stuff is *amazing*
> I didn't realise you can automate any windows operation - this is very cool. There's
> lots of documentaion on the arguments to the messages on this site.
> 
>    Then I found polyML
> 	
> 	http://www.polyml.org/docs/Windows.html
> 
> 
>    In particular
> 
>    http://www.polyml.org/docs/Winref/Message.html#PostMessage
> 
> 	
>     The polyml distribution has all the answers 
> 
>      Writing a native window app in polyML is "easy" (TM)
> 
>    See
>    
> 	http://www.polyml.org/docs/mlEdit.html
> 
> 
>     Reproducing this in Erlang seems not unreasonable.
> 
> 
>     Then I thought to myself "can I write postMessage, sendMessage etc. as BIFs"
> this requires compiling Erlang on windows :-(
> 
>      I tried mingw - no success so I read the read me on "compiling for windows" -
> double yuck.
> 
>     So I thought "how do I write a port program for windows" - and we're back to
> "interfacing Erlang to C" - triple yuck.
> 
>     Now all the methods for interfacing Erlang to C suck greatly. Why can't you just
> make a generic metacall from erlang to C - is this possible? - answer "possibly"
> 
>     Then I found 
> 
> 	http://www.haible.de/bruno/documentation/ffcall/avcall/avcall.html
> 
>      Avcall is part of the ffcall package - now this looks hopeful and does compile
> under mingw.
> 
>      So now the plan is this:
> 
>      Use avcall to write a generic interface to the win32api
> 
>      Implement PostMessage SendMessage and CreatWindowEx using the generic interface
> write a simple windows app with the above, then recode the polyML stuff in Erlang.
> 
>       This is leading me into unexplored terratories - since I know *nothing*
> about the problems of compiling C apps on windows - I'd like to end up with
> rock solid native compiled winapi applications - 
> 
>       I really like some feedback here from a real windows expert - are my statements
> about windows correct, is the API as simple as it appears to be?
> 
>       The really interesting observation is that the underlying windows GUI architecture is
> a pure message passing system - (Like X) - which should mean that it will interface
> well with the Erlang process model (like the X11 ex11 code did).
> 
>       Is this observation correct?
> 
> 	/Joe
>