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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e429176c9adb07b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-21 10:05:50 PST Message-ID: <3E5669C8.30305@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: [OT] Best way to isolate a GUI? (The final concensous?) References: <3E511C15.1040404@acm.org> <3E5121BD.4010200@cogeco.ca> <3E51A55A.3000101@cogeco.ca> <3E52A1BF.1020809@cogeco.ca> <3E53CE60.1030008@cogeco.ca> <3E55501D.9050006@cogeco.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 21 Feb 2003 13:02:48 -0500 NNTP-Posting-Host: 198.96.47.195 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1045850569 198.96.47.195 (Fri, 21 Feb 2003 13:02:49 EST) NNTP-Posting-Date: Fri, 21 Feb 2003 13:02:49 EST Organization: Bell Sympatico Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: archiver1.google.com comp.lang.ada:34355 Date: 2003-02-21T13:02:48-05:00 List-Id: Marin David Condic wrote: > Well, if you use an existing GUI such as Windows or Motif, you are *going* > to have callbacks. I'd prefer to isolate them in some kind of wrapper layer > and have the "real" app receive messages of some sort. If you were building > a GUI from bottom dead center, you could build that sort of thing right in. > I'm just saying I think that callbacks are an ugly kludge that I'd prefer > were done a different way. You might be able to get there with existing GUIs > & glue or wrappers or skins or whatever you like to call it. Just expressing > a desire to see an interface to a GUI that doesn't have to know anything > about the code *I* write. :-) > > MDC If we were to belabour this discussion a bit further, it seems to me there are two points worth discussing here: 1) What is it about callbacks specifically that you don't like? I think this needs to be defined beyond "ugly kludge". 2) What other suitable models are there (with pros/cons)? The problem that we're dealing with here is an event driven system. Callbacks are similar to interrupt programming as you've stated. Outside of the callback (in most GUI apps), you have a main loop that basically receives events and dispatches them (invoking ultimately in some cases, callbacks). The things I dislike about callbacks include: 1) restricted access to application data (normally just "user data"). 2) each event code is a separate procedure (some may see this as a feature). 3) code restrictions: ie. you must not tarry too long there, or you'll hang the main loop (making it not respond to more GUI events). 4) more code restrictions: sometimes there are some GUI related operations that are restricted within a callback (much like malloc() is unsafe in a UNIX signal handler). If we were to move to a task centric model, how would the application register (link) a task entry (queue) to a specific widget? It has been a while since I have played with tasking, so is it possible (for example) to gain the address of an entry (queue)? (This is similar to the idea matching Qt's signals with slots, except we've introduced a tasking model). Assuming you can't take the address of a task entry, the only way I can see this working is via a procedure (callback) that then calls the task entry (a layer proc). One should note however, that "main loop" hangs are still possible if you don't plan your task model correctly. For example if one event takes too long and another comes along before it finishes (because the user is clicking the button again), the rendezvous will block until the task is able to accept another request. To avoid this of course, you could pass off the request to a separate task, but then you'd have to manage the backlog that an impatient user might create by hammering a button repeatedly. I am having a little trouble picturing how this tasking model can be done, with my limited experience with tasks in Ada. Would you be able to use a entry "family" number to link these together dynamically by use of the number? I'll have to dig out my tasking book tonight. I am intrigued by this idea.. just trying to picture a practical implementation of it. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg