Re: Custom model in gtkada?

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

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

>> How many GUI programs have you written? With how many different toolkits?
>> 
>> I've used Visual Basic (essentially tagged, I think :), Borland's C++
>> framework (tagged/dispatching), Windex (Ada tagged), GWindows (mixed
>> tagged/pointers), and Gtk (pointers).
>
> I used MACRO-11/Asynchronous System Traps + full-duplex terminal driver, (I
> guess, it should be classified as callbacks (:-)), FORTRAN/FMS,
> Ada83/C/TPU, C curses, Borland Turbo Pascal and later Delphi, C/C++
> X11/Open Look, ANSI C LabVindows/CVI, Ada/C++ Windows API, LabView, Diadem
> (graphical languages), now GtkAda.

Excellent; we have some experience in common.

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

> BTW, Gtk_Tree_Model is a clear candidate to become an interface. Thanks to
> Maxim Reznik, I made an abstract tagged type from his code. It works fine
> by now.

Yes, there are many places where GtkAda can be made better thru Ada's
typing mechanisms.

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

> 2. I don't see how events may influence the choice between pointers to
> subprograms and primitive operations.

You are correct, that is an orthogonal choice. 

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

>>> Another point, a list of pointers to subprograms is in no way better than a
>>> list of tagged objects (with primitive subprograms).
>> 
>> Why?
>> 
>> I would find a list of tagged objects confusing.
>
> As I understood it, the point was made that procedures are good to chain a
> list of event handlers. I see no difference between maintaining a list of
> procedures vs. a list of handlers (objects). They are equivalent.

Ok, at the level of "maintain a list", yes, they are equivalent.

-- 
-- Stephe