Re: A community Windows binding

[tmoran@acm.org]

>I have long felt that the approach most suited to a concurrent language
>(such as Ada) is for the 'window manager' to be a separate task, or
>possibly many tasks.
  Claw has a (hidden) separate task for the window manager.

>The window manager calls -- via callbacks, or (better) dispatching -- the
  Claw uses dispatching.

>'draw' procedures of a registered set of 'visual components', in response
>to the movement, resizing, uncovering, deminimisation, etc., of those
>components, as they are placed on the screen. The window manager may do the
>actual drawing itself directly to the hardware, or it may be a proxy for an
>underlying subsystem. I appreciate that this model doesn't fit Win32
>perfectly, but it can be done.
  When, eg resizing, is done by the user, the Claw window manager calls
(by dispatching) the programmer's "When_Resize" procedure, which in turn
may make calls to draw the various objects that should be visible in the
resized window.

>All that a simple program (with no separate tasks of its own) needs to do
>is to set up the components, and register them with the window manager.
  In Claw (for non-trivial programs) the programmer defines, eg,
type My_Stereo_View_Window_Type is new Basic_Window_Type with ...
procedure When_Resize(Window : in out My_Stereo_View_Window_Type; ...
A call to the (inherited) Create procedure creates the window (usually
also displaying it).  On a resize event for a window, dispatching goes
to the appropriate When_Resize procedure.

>Its main data needs to be protected (in protected objects), so that it can be
>accessed concurrently by the components' draw (and other) procedures, as
>they are called by the window manager.
  Most windows programs do everything on an interrupt, er, event basis
so there's really only one task - the window manager - doing anything.
The main program merely sits and waits for the window manager and other
tasks to finish.
  But you're quite right, if the main program or other tasks needs to
non-trivially access shared data protected objects will likely be appropriate.

>However, this is all very idle and speculative.
  Hardly, see www.rrsoftware.com/html/prodinf/claw.claw.htm