Re: Custom model in gtkada?

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

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

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

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!

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.

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.

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

Well, that's an extreme definition. By that definition, no existing
GUI has an event queue.

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

Indeed, in Microsoft Windows, the "events" are called "messages". In
Gtk they are called "events". I don't know what they are called in X
Windows.

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

> Windows DCs are much like transactions.

I assume "DC" = "Device Context". Yes, they do have start/operate/end
semantics. But no "roll back".

In Windex, I did the "start" and "end" parts in the top level message
handler, leaving only "operate" up to the client. That made things
simpler.

I assume the Gtk implementation for Windows uses DCs at the bottom
layer; it must do the start and end like Windex does.

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

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?

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

So that "order" is a GUI event, and the timing of that event is based
on how humans process visual information (minimum flicker rate
requirements). That's a good design.

> But obviously keyboard input would represent an opposite case, where
> polling would be wrong. 

Yes.

> One could, and usually all GUI libraries do it, add some timer event
> or message. 

To handle events that have timing requirements, but are asynchronous
from others, yes. Not to handle keyboard input.

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

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

-- 
-- Stephe