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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,37023471dc2e1934 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!kanaga.switch.ch!switch.ch!news.belwue.de!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Custom model in gtkada? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <3ndpd7br1nn9$.vkcrts8e898z.dlg@40tude.net> <20060614210028.GA18024@ws.max.zp.ua> <44917d39$0$4495$9b4e6d93@newsread2.arcor-online.net> <44941be9$0$11065$9b4e6d93@newsread4.arcor-online.net> <14e2r2ftir9ok.i8u1axnplx11.dlg@40tude.net> <449a432e$0$15869$bb6a4dc3@news.uunet.fr> <10aj6ifazzw9q$.1ks15eefzi4kn.dlg@40tude.net> Date: Fri, 30 Jun 2006 14:29:25 +0200 Message-ID: NNTP-Posting-Date: 30 Jun 2006 14:29:25 MEST NNTP-Posting-Host: 6a5abf7a.newsread2.arcor-online.net X-Trace: DXC=;EQoQ\0Ec2Hndh];1CKbgLQ5U85hF6f;DjW\KbG]kaMHGSi?jHD8GO@j4f22Mm7Z>N[6LHn;2LCVN7enW;^6ZC`DIXm65S@:3>O X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:5332 Date: 2006-06-30T14:29:25+02:00 List-Id: On Thu, 29 Jun 2006 13:11:12 -0400, Stephen Leake wrote: > "Dmitry A. Kazakov" writes: > >>> I think Gtk is the best model, although the C underpinnings make >>> things difficult sometimes. In particular, it is difficult to detect >>> some errors at compile time, that the fully Ada systems can detect. At >>> root, the C pointers are not strongly typed. >> >> I don't see how Ada could help there. An event is either handled or not. >> "Event" is not an Ada term, so the compiler cannot check anything. An >> abstract primitive subprogram is. > > An Ada pointer to a subprogram is also strongly typed; that's what's > missing in the C code. You can easily specify a pointer to a > subprogram with the wrong parameter profile. If you are lucky, the > error will be caught at runtime, with a sort-of-helpful error message. Yes, but what pointers lack is safety of composition. Primitive operation is safely inherited and required to be overridden when abstract. Also within a primitive subprogram you are safe against re-dispatch. An equivalent design based on pointers will always "dispatch". >> 1. There are many communication / synchronization / notification >> mechanisms. Among them events are not necessarily the best. > > Well, of course. But that's not a very helpful statement. > > For the specific case of windowing Graphical User Interfaces, I think > events are the best. For many other applications, they are not. For all, GTK events are probably not events, but some kind of dispatching for poor. A 'true' event has no parameters and its handling is asynchronous to the emitter. They lack serialization. IMO, GUI are better with messages, because quite often the emitter needs to resynchronize itself with the server to be sure about the state of the widget. It could also need to receive some data back. Probably, a kind of transaction would even better, considering low-level drawing, double buffering issues etc. Windows DCs are much like transactions. Another orthogonal problem is safe composition: widgets as containers, extensible widgets. Here I don't see nothing better than some sort of polymorphism. Events and messages are spaghetti. An alternative approach would what we have for finalization. When a record is finalized all its members will be finalized as well. Widget containers handle signals in similar manner. >> 3. I designed soft-real time GUI libraries for Windows, where control over >> resources and multitasking was essential. Especially because the data rates >> (1-10ms) were sufficiently higher than the visualization rates (100ms). I >> don't think that event/callback mindset is any good for such things. At >> least it would require a lot of acrobatics. > > Clearly you don't generate GUI events for every real-time data point. > > What is better than events, for this application, in your opinion? And > most importantly, why? In this particular case polling is better than events. The widgets are not controlled by data flow. Instead of that there is a refresh engine which orders the widgets to redraw themselves. But obviously keyboard input would represent an opposite case, where polling would be wrong. One could, and usually all GUI libraries do it, add some timer event or message. But this makes things worse. A clean serialized model becomes in fact asynchronous, because the sources of timer events and "normal" events are asynchronous. IMO, Ada could provide a much cleaner view on these things, especially, because it is natively multitasking. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de