Re: Custom model in gtkada?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 04 Jul 2006 09:51:56 -0400, Stephen Leake wrote:

> "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.

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