From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,4b27f494a96e0530 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Nick Roberts Newsgroups: comp.lang.ada Subject: Re: A community Windows binding Date: Fri, 08 Oct 2004 03:43:28 +0100 Message-ID: <2smd6iF1mo0mcU1@uni-berlin.de> References: <2004100600261150073%david@bottoncom> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de gMRuly3Xl/hC8UOrUJM81gtRkZE09MxPuCYdEFSh5G/1bO0og= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en In-Reply-To: Xref: g2news1.google.com comp.lang.ada:4909 Date: 2004-10-08T03:43:28+01:00 List-Id: 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