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!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!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> <191m62k8p0wpz.qjuymnpvpl0p.dlg@40tude.net> Date: Wed, 5 Jul 2006 15:06:09 +0200 Message-ID: <142sco0zplhvp$.nycy57t27oj3.dlg@40tude.net> NNTP-Posting-Date: 05 Jul 2006 15:06:09 MEST NNTP-Posting-Host: 36cf232b.newsread2.arcor-online.net X-Trace: DXC=J=2M@?j0;P3a9jkkC[6LHn;2LCVN7enW;^6ZC`DIXm65S@:3>O X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:5505 Date: 2006-07-05T15:06:09+02:00 List-Id: On Tue, 04 Jul 2006 09:51:56 -0400, Stephen Leake wrote: > "Dmitry A. Kazakov" writes: > >> On Sun, 02 Jul 2006 11:17:17 -0400, Stephen Leake wrote: >> >>> "Dmitry A. Kazakov" writes: >>> >>>> 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! >> >> No I don't. More precisely I don't want it be the default. It is unsafe, >> because some non-overridden behavior [already implemented and tested] of a >> widget might change if some signals get overridden. Consider F1 emitting >> F2. Let F2 is overridden while F1 is not. This would mean that F1 might >> function differently. If W1 emits F1 it shall function exactly as it was >> before W2 was derived from it. > > Yes, that is an inherent problem in user-overridable subprograms that > are "supposed" to call other subprograms; there is no way to > enforce/check that behavior. But tagged types in Ada enforce it. You dispatch only once. When W1.F1 calls to F2 that is W1.F2 and never W2.F2, unless the argument is explicitly converted to W1'Class. >>>> 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? >> >> Rollback upon exception would be nice. I agree, it is close to Ada >> rendezvous. Messages are also close to rendezvous, one can route them etc. >> However rendezvous lack marshaling, I am not sure if it is [always] >> bad. > > The marshalling packages in GtkAda are supremely confusing. I'd much > prefer an inheritance mechanism there. I started trying to extend > GtkAda to provide one, but I didn't have time to really work on it. > It's not a simple problem. > > But I think marshalling is necessary to any real GUI event handling. Rather to any asynchronous event. If handling is synchronous, i.e. the emitter is blocked until the action will take effect, then there is no need to marshal anything. I'm not sure about the relation, but it seems that a great majority of events are synchronous. Another part is asynchronous, but can be pipelined as a conveyer. This would be a sort of "transaction" model. The rest (actually minor) is fully asynchronous - fire and forget. Only for the rest one needs "hard" marshaling. BTW, There is another way. Gtk marshals everything though it supports garbage collection. The problem is that they didn't care to provide object views, so that a mutator action would clone the object if anybody else still uses it. That would be "marshaling on request." >> But of course, I'll help in what I can. > > Ok. The GWindows project is part of the Gnavi Sourceforge project; see > http://sourceforge.net/projects/gnavi/ . It's not very active, but > this might trigger some work. I'll take a look, when I finish my current project. I am not sure, is it Gtk-based or Windows API? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de