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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable 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-22 21:19:23 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!fr.usenet-edu.net!usenet-edu.net!enst.fr!not-for-mail From: "Robert C. Leif" Newsgroups: comp.lang.ada Subject: RE: [OT] Best way to isolate a GUI? (The final concensous?) Date: Sat, 22 Feb 2003 21:18:49 -0800 Organization: ENST, France Message-ID: Reply-To: "comp.lang.ada mail to news gateway" NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: avanie.enst.fr 1045977562 34804 137.194.161.2 (23 Feb 2003 05:19:22 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Sun, 23 Feb 2003 05:19:22 +0000 (UTC) To: "'comp.lang.ada mail to news gateway'" Return-Path: X-Envelope-From: rleif@rleif.com X-Envelope-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.1 Precedence: list List-Id: comp.lang.ada mail to news gateway List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: archiver1.google.com comp.lang.ada:34462 Date: 2003-02-22T21:18:49-08:00 Marin Condic wrote, "Give it some thought. I think that one might be = able to evolve some kind of low-level wrapper/post-office/client-server thingie = that could decouple the app from the GUI in a way that might allow multiple = GUIs and GUI builders to be working at the other end." I suspect that this "thingie" could be an extensible protected type. It would be a combination of a tagged and a protected type. It was = suggested at SIGAda 02 that this construct would be very useful for real-time code. I hope that one of the Ada language experts who attended SIGAda might comment on this. Bob Leif -----Original Message----- From: Marin David Condic [mailto:mcondic.auntie.spam@acm.org]=20 Sent: Saturday, February 22, 2003 6:50 AM To: comp.lang.ada@ada.eu.org Subject: Re: [OT] Best way to isolate a GUI? (The final concensous?) Warren W. Gay VE3WWG wrote in message news:3E5669C8.30305@cogeco.ca... > > 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". > I kind of expressed that in another post. It means that the GUI has = intimate knowledge of my code - much like a computed goto or passing path-flags = into a procedure. It dictates to me what my app must look like (Thou shalt = have a procedure that looks like this and has these parameters and will react = in this way to this event. What if I want to deal with that event in a = task? What if I want one big procedure dealing with 50 different events? What = if I want to run around the office stark naked with a rubber glove on my head yelling "I'm A Squid! I'm A Squid!" :-) It's none of the GUI's business = what I do or how I choose to do it. It needs to provide me with some sort of "event" and I need to figure out what to do with it from there.) = Callbacks also start dictating to you that you do things with a particular = language - or at least calling convention. You can write Ada callbacks for C-ish = GUIs - its just painful. I'd prefer something language agnostic and messages = are much more in that realm. I think apps are beter designed when the only = thing they see is the *data* rather than the mechanism by which the data gets there. Messages/Events are going to be closer to simply reading a data = file than callbacks are going to look like. For those reasons and more, if I = were to invent a GUI from bottom dead center, it wouldn't have a single = callback in it. > 2) What other suitable models are there (with pros/cons)? > Since you're dealing with an "event" of some sort - you've got a kind of "command/response" protocol - albeit, possibly very asynchronous and = loosely coupled. I've seen a couple of ways of handling that with messages. You build one big hose and send all the data up and down that hose (a single queue) or you create some kind of mailbox/post-office kind of thingie = where various threads of an app (or processes in a computer) register for = events they are interested in and they start receiving them in their mailbox. = If they want to communicate with some other part of the system, they post a letter via the post office. Both are going to consume a bit more time = than a callback will, but I think thats negligible for most apps. Both require = some level of message management underneath the GUI skin. Both are going to require that you have some rather large catalog of messages - but no = worse than having a large catalog of callbacks. Its been done before, so it isn't really radical. I've seen OS's that = have "Events" that an app registers for. I've seen big military systems that = have very complex "postal systems" - sometimes they get unwieldy because the message traffic is ill defined and the communications are so = asynchronous & uncertain - but for a simple client/server kind of thing its not likely = to be that big a deal. > 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). > See above. An interrupt can be an "event" that results in a message to = the app. You can tie a procedure to an interrupt. You can tie a task entry = to an interrupt. You can have a universal interrupt handler that creates = "events" for the app. All of them work, but "events" are much more like reading a simple file. > 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). > I wouldn't try to hook tasks to the events generated by a widget. That's just a callback wearing a different suit. I'd create a protocol of = messages. The app starts up and sends to the GUI whatever initialization is = required to get the windows defined & displayed. (A big XML file like what GtkAda uses to define windows?) The windows and widgets and what have you all = have some kind of identifier associated with them - a unique ID. One or more tasks want to make something happen, they build a message targeted to = the unique ID of interest and send it to the GUI. The user cliks buttons or types text or whatever, the widget concerned packages up a message and = sends it (with its ID) to the app. The app just has to figure out what to do = with the messages it gets. Like I said, the messages to/from the app/GUI might want to be handled = by a "post office" so that individual tasks can decide what events they want = to see, but that's just another layer of abstraction on top of the message system, so it depends on how complex you want to go. > 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. > Don't do that and it will stop hurting. :-) Use messages and decide on = what to do if you start getting duplicate messages or floods of them. Start dropping them on the floor? The user clicks the button 37 times you = react to it 37 times even if it takes you a while? Handle each widget with its = own task and buy a really massive multiprocessing computer to handle the thousands of tasks it will have? I think as long as you have a message protocol, you're free to figure out numerous ways of handling the = traffic. > 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. > The task starts, it registers for the events it is interested in = (opening files, if you will) and then hangs on some kind of "Receive the next message" procedure. It quits when it gets the "Shut yourself down" = message. Everything else is some form of case statement or dispatch based on the message received. > I am intrigued by this idea.. just trying to picture a practical > implementation of it. > Give it some thought. I think that one might be able to evolve some kind = of low-level wrapper/post-office/client-server thingie that could decouple = the app from the GUI in a way that might allow multiple GUIs and GUI = builders to be working at the other end. It might be worth making some kind of = attempt at a limited prototype to see how it might work in practice.....hmmmmmm MDC -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/ Send Replies To: m c o n d i c @ a c m . o r g "Going cold turkey isn't as delicious as it sounds." -- H. Simpson =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D