Re: Custom model in gtkada?

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

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.

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

Yes, it is Turing complete. (:-)) I'd like to have "class-wide" and
"primitive" equivalents of signals.

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

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

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

Yes, that's a problem

> 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, how can I recommend them? But of
course, I'll help in what I can.

>> 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?

Maybe model-view-controller design and decomposition across these lines.

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

Yes, but I suspect that in the most cases these events serve
multitasking-for-poor purpose. Ada is natively multitasking, so these
events could be replaced by explicit calls from tasks, rather than
callbacks from main loop or a hidden thread.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de