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,37023471dc2e1934 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!atl-c08.usenetserver.com!news.usenetserver.com!pc02.usenetserver.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Custom model in gtkada? 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> From: Stephen Leake Date: Sun, 02 Jul 2006 11:17:17 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:z5L04wYSu4vdqqm87uv0z6wzsYY= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: 6aab944a7e38c63d2959d21461 Xref: g2news2.google.com comp.lang.ada:5410 Date: 2006-07-02T11:17:17-04:00 List-Id: "Dmitry A. Kazakov" writes: > 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". This is true, but I don't see how it is relevant to a GUI design. Of course you want the call to "dispatch" to the user-provided operation! If the GUI designer derives a new widget from an existing widget, the designer must arrange for the callbacks to work properly. That can be done with the pure pointer model, or with inherited operations. I have not done much with deriving new widgets from existing widgets. The few times I tried it I ended up with a totally new widget. I'd have to go back and re-examine the details to understand why. >>> 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. Well, that's an extreme definition. By that definition, no existing GUI has an event queue. > 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. Indeed, in Microsoft Windows, the "events" are called "messages". In Gtk they are called "events". I don't know what they are called in X Windows. > 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. By "transaction", you mean something like an Ada rendezvous? Or like a database transaction, with start, operate, end/rollback semantics? > Windows DCs are much like transactions. I assume "DC" = "Device Context". Yes, they do have start/operate/end semantics. But no "roll back". In Windex, I did the "start" and "end" parts in the top level message handler, leaving only "operate" up to the client. That made things simpler. I assume the Gtk implementation for Windows uses DCs at the bottom layer; it must do the start and end like Windex does. > 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. The Gtk container widgets work pretty well for layout (position and sizing of windows). They fail miserably when it comes to composing event handling. I never implemented container widgets in Windex. GWindows now has Packing_Boxes, based on my experience with Gtk containers. We still have not figured out a good way to compose the event handling. Perhaps you'd like to help with that? >>> 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. So that "order" is a GUI event, and the timing of that event is based on how humans process visual information (minimum flicker rate requirements). That's a good design. > But obviously keyboard input would represent an opposite case, where > polling would be wrong. Yes. > One could, and usually all GUI libraries do it, add some timer event > or message. To handle events that have timing requirements, but are asynchronous from others, yes. Not to handle keyboard input. > But this makes things worse. A clean serialized model becomes in > fact asynchronous, because the sources of timer events and "normal" > events are asynchronous. Well, of course; that's reality. "serialized" means "in time order, routed to the correct window". It does _not_ mean "synchronized with some clock". Why is that "worse"? What is the alternative? > IMO, Ada could provide a much cleaner view on these things, especially, > because it is natively multitasking. Yes. But it doesn't eliminate the need for GUI events driven by timers. -- -- Stephe