Re: Custom model in gtkada?

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

On Thu, 29 Jun 2006 13:11:12 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>> I think Gtk is the best model, although the C underpinnings make
>>> things difficult sometimes. In particular, it is difficult to detect
>>> some errors at compile time, that the fully Ada systems can detect. At
>>> root, the C pointers are not strongly typed.
>>
>> I don't see how Ada could help there. An event is either handled or not.
>> "Event" is not an Ada term, so the compiler cannot check anything. An
>> abstract primitive subprogram is.
> 
> An Ada pointer to a subprogram is also strongly typed; that's what's
> missing in the C code. You can easily specify a pointer to a
> subprogram with the wrong parameter profile. If you are lucky, the
> error will be caught at runtime, with a sort-of-helpful error message.

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

>> 1. There are many communication / synchronization / notification
>> mechanisms. Among them events are not necessarily the best.
> 
> Well, of course. But that's not a very helpful statement.
> 
> For the specific case of windowing Graphical User Interfaces, I think
> events are the best. For many other applications, they are not.

For all, GTK events are probably not events, but some kind of dispatching
for poor. A 'true' event has no parameters and its handling is asynchronous
to the emitter. They lack serialization. IMO, GUI are better with messages,
because quite often the emitter needs to resynchronize itself with the
server to be sure about the state of the widget. 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. Windows DCs are
much like transactions.

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.

>> 3. I designed soft-real time GUI libraries for Windows, where control over
>> resources and multitasking was essential. Especially because the data rates
>> (1-10ms) were sufficiently higher than the visualization rates (100ms). I
>> don't think that event/callback mindset is any good for such things. At
>> least it would require a lot of acrobatics.
> 
> Clearly you don't generate GUI events for every real-time data point.
> 
> What is better than events, for this application, in your opinion? And
> most importantly, why?

In this particular case polling is better than events. The widgets are not
controlled by data flow. Instead of that there is a refresh engine which
orders the widgets to redraw themselves. But obviously keyboard input would
represent an opposite case, where polling would be wrong. One could, and
usually all GUI libraries do it, add some timer event or message. But this
makes things worse. A clean serialized model becomes in fact asynchronous,
because the sources of timer events and "normal" events are asynchronous.

IMO, Ada could provide a much cleaner view on these things, especially,
because it is natively multitasking.

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