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!news4.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> <191m62k8p0wpz.qjuymnpvpl0p.dlg@40tude.net> From: Stephen Leake Date: Tue, 04 Jul 2006 09:51:56 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:7nuyaunvJPuLkIWq6MXH+ddM2PY= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: 0a6bd44aa7289e73ae4a427431 Xref: g2news2.google.com comp.lang.ada:5479 Date: 2006-07-04T09:51:56-04:00 List-Id: "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. However, that is not unique to GUI event handling; it is a general problem of subprogram operation specification. I would call it a bad design to define such a callback. Or at least, such a callback should be clearly labeled as "expert" or "dangerous". > Yes, it is Turing complete. (:-)) I'd like to have "class-wide" and > "primitive" equivalents of signals. That's an interesting concept. But Gtk is already complex enough :). >> 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. > > Once I wrote an extensible dialog widget for Windows (in C++), which was > something like a mixture of Gtk.Boxes and a stack of widgets (subdialogs), > combined with messages handling. It was nasty. Especially handling messages > was. Because some messages propagated up the hierarchy, some did down. A > subdialog could either swallow a message (give a response), or let it > propagate. That was combined with a possibility for a widget to close > itself (and let swallow or propagate). A subdialog could catch events like > button clicks of its parents. Add here a translation of messages parameters > upon propagation... Right. That's where I have problems with Gtk as well. Windex (my "pure Ada" binding to Win32) is a little better, because I can use Controlled types for some things. But I'm still not clear how to handle message propagation cleanly. On the whole, I think Gtk does the best job in GUI library design. But it's far from "perfect". >>> 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. >> 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? > > I am not satisfied with my own solutions, Neither am I, with mine :). > how can I recommend them? Dialog is almost always useful; the combination of two not-so-hot ideas can sometimes produce a good solution :). > 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. -- -- Stephe