Discussions about GUI design in Ada

General
1

I don’t see how it could work.

If you create a button (a function will return a button structure you can use to change the colours, text and other things). But how will you link the button with a given task. ? I guess that in Ada we can only call a task service with:

The_Task.Service_Name(arguments);

And here, The_Task is a static name, and not a variable given to the button initialisation functions.

However, you can call Set_callback(A_Button, A_Callback’access);, I know no équivalent with tasks.

And nothing prevents you to have a callback based GUI library and use callbacks that call a task service. Idem with an object based library.

2

I think you are talking different things. An implementation of event posting (however in a GUI many events are processed synchronously, e.g. programmatically emitted events, rather than input ones) is a very low-level thing hidden by the framework in a messages loop and translated into a higher level primitive operations (methods/callbacks) of the widgets. If the proposal is to sit in the basement rather than to go to at least the first floor that would be indeed awful, but it is unclear if that is the proposal. There is nothing static in

Messages_Handler.Send (Button, Click_Event);

Messages_Handler can be a task object.

The architectural GUI problem of widget hierarchy is that while it, augmented by aggregation/composition (container widgets), reflects our understanding of GUI, it puts event handing upside down when a button sends “clicked” to itself. The actual recipient must catch it by connecting handlers/callbacks, whatever. So while the visual aspect is nicely represented the functional logic is a hodge-podge of assorted unstructured subroutines chaotically distributed all over the application.

A solution must address this in the first place. IMO. If not, GtkAda will serve you well.

3

Ada GUI does not link widgets with anything. I suggest you read the package specification and some of the test/demo programs.

4

Let me just name a few road blocks from the language perspective:

  1. Stateful co-routines (lack of). We do not want have a task per widget. There should be close to zero cost tasks having same interface as full tasks.

  2. Multiple dispatch or alike (lack of). There is a sender and receiver in each GUI action (e.g.

    procedure Click (Button, Whatever)

    In a statically typed safe language we want to describe such things in a safe, typed manner.

  3. Delegation (you want events propagate from members of a container up to the container). Again, in a structured safe and typed manner.

5

Regarding this particular bit: A task can implement a limited, synchronized, or task interface which you can then pass around a class-wide access type of.

6

There is no full multiple-inheritance in Ada. Therefore you cannot have a partially implemented interface as required for processing event where you filter out some event and let propagate others. You can do this in Ada with tagged types, but that hierarchy is already occupied by the widgets and there is no place left to the hierarchy of events.

There are OO patterns to deal with this, all resulting in quite complicated designs.

7

Hi all,

I moved the discussion to a separate thread so as to keep the Project Ideas discussion only related to the idea itself and what is being proposed. This will help the Awards people to read the relevant posts about the idea itself.

Nevertheless, feel free to continue the topic here or suggest a better title for the thread, I didn’t really know how to make it more accurate.

Best regards,
Fer