Re: Custom model in gtkada?

[Stephen Leake <Stephe.Leake@nasa.gov>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 02 Jul 2006 11:17:17 -0400, Stephen Leake wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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