Re: A community Windows binding

[Nick Roberts <nick.roberts@acm.org>]

Jeffrey Carter wrote:

> Between callbacks and the single queue of events for all windows of JEWL 
> is an approach more suited to concurrent languages: multiple queues, one 
> per top-level window, with the assumption of one task per queue/window. 
> There should be the ability to select what events will be put in the 
> queue, and the possibility to combine queues when a window doesn't merit 
> its own task. Such an approach should scale better than JEWL's single 
> queue, and be more readable than callbacks.

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.

The window manager calls -- via callbacks, or (better) dispatching -- the 
'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.

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. 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.

However, this is all very idle and speculative.

 > What would be ideal would be an Ada-centric windowing library, with
 > implementations based on Win32, X, and the like.

Which sounds like Titian. But, as I mentioned elsewhere, this would be a 
huge project.

-- 
Nick Roberts