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!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed.cwix.com!news-in.mts.net!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: A community Windows binding References: <2004100600261150073%david@bottoncom> <2smd6iF1mo0mcU1@uni-berlin.de> In-Reply-To: <2smd6iF1mo0mcU1@uni-berlin.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 14 Oct 2004 12:46:34 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1097772393 198.96.223.163 (Thu, 14 Oct 2004 12:46:33 EDT) NNTP-Posting-Date: Thu, 14 Oct 2004 12:46:33 EDT Organization: Bell Sympatico Xref: g2news1.google.com comp.lang.ada:5205 Date: 2004-10-14T12:46:34-04:00 List-Id: Nick Roberts wrote: > 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. At the end of the day, a task begins to look like a callback, with the exception that the delivery mechanism is different. I can only see 4 ways to deal with GUI events : 1. The JEWL big main loop approach 2. The callback approach (Windows) 3. The "pipeline" event approach (X Window) 4. The "method" calls in an OO structure for certain events (Java/C#), and the use of inheritance to gain control during certain events. This is very similar to #2, except that inheritance allows installed callbacks through overrides. Ada tasks IMHO, are a variation of #2. In fairness, #4 is very similar to #2 as well. I don't believe #1 is practicle for a large application: - the main loop is too large code-wise - many cases (harder to modularize) - unwanted coupling between cases is possible through shared objects/code in the module containing the main loop(though this can be avoided). People dislike #2 for various reasons: - perhaps complexity - distributed code (too little coupling?) - difficulties with "user data" parameter/type The X Window approach has its own problems: - performance: latency between request and event response (in synchronous mode), but this makes error handling easy and neat. - error handling: (asynchronous mode) it is very messy tracking requests vs returned responses (often X Window programs ignore returned errors because they were n events ago). This leads too poor quality of app. My biggest beef for callbacks and similar techniques is the need for the "user data" parameter. I don't have a problem with the callback mechanism itself, but for Ada the "user data" type and parameter is usually a problem. If however, some main object for an application was used and made available in every callback, then the application can extend that and gain access to custom application values. I seem to recall that some GUIs do it this way, which seems about right to me. ... > 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. But the process is much the same. Registering a callback or an object, is a very similar process (or burden ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg