Towards a native windows GUI

[Joe Armstrong (AL/EAB)]

Hi Serge,

To answer your comments:

To start with I get the same feeling looking at the windows API as I got when looking 
at XLib and the X11 protocol - on the surface the XLib programming model and the
windows model look very complicated - but deep down they get much simpler.

A GUI is best modelled as lots of small parallel processes where each control
(button, toggle, entry, ...) is a parallel process. To get it to do something
you sent it a message (PostMessage) to query it (example, reading an entry) you send it a message and wait for the reply (SendMessage).

Now Erlang is very good at managing lots of small processes, where each process
does very little (that's what it was designed to do).

Programming a GUI as a collection of parallel processes is very easy. But programming
a GUI as a single sequential process is very difficult.

That's the reason for XLib, Motif and Win32 MFC etc. To make this difficult process
easier.

The Delphi statement 

> Button.Caption := 'OK';

Probably just boils down to a few PostMessages calls.

I also see no reason why this should not be handled by the Erlang emulator.

As I see things 

	- writing new BIFs is easy, but
	- writing port programs is messy

So to include foreign language code we should think in terms of running several
Erlang nodes on the same machine. One node (the safe) node should be "unpatched"
the other nodes can have user-added BIFs (these are unsafe). The safe node can then request operations in the unsafe nodes with distributed Erlang RPCs.
  
As for Vlad's concern about the efficiency of dispatching all messages in the
Erlang top-loop, this might be a problem, until an experiment is performed 
I don't know.

In the X11 case handling all X11 protocol messages in Erlang was not markedly slower than in C - often faster.

My view is that if what's at the bottom is simple (ie GUIs work by sending messages
to controls) and Erlang is designed for just that, then removing all the middleware
might be the way to go.

<< aside - It's not that I dislike GTK+, Pango, gnome canvas, SDL, Cairo, Motif
   whatever, but getting these things to work together is a pain. I actually want to
   use these libraries and not fight with them. Most often building them at all is
   painfully difficult. >>

/Joe



> -----Original Message-----
> From: Serge Aleynikov [mailto:serge@REDACTED]
> Sent: den 17 augusti 2005 15:19
> To: Joe Armstrong (AL/EAB)
> Cc: erlang-questions@REDACTED
> Subject: Re: Towards a native windows GUI
> 
> 
> 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
> > 
> 
>