Event mechanisms for GUI's

Event mechanisms for GUI's

[Lucretia]

Hi,

My wxAda project stalled due to a problem with C++. I'm starting on a
new project to see if I can do better than wxAda using native Ada and
binding only where necessary. It will do what wxWidgets does and
provide native controls for different platforms, i.e. GTK+-2.x for
Linux, Win32 API, etc. I'll be implementing it in Ada 2005 as well, as
long as the FSF GNAT doesn't cause too many problems.

I'm currently thinking of the event handling mechanism, I started to
think about using the listener/subject pattern, but then started to
wonder about the alternatives:

1) Event loops

This would be painful as there'd be a lot of case statements.

2) Signals & slots

This just seems to be a simplification of (5), where instead of using
an observer interface you just pass a function pointer and the signal
can contain many of these function pointers.

Can be implemented using generics to provide type safety.

3) Extension of tagged-types (like CLAW)

Not a bad idea, just override the subprograms you want to know about.

4) Ada.Real_Time interrupts

I don't know enough about this, so I won't even comment.

5) Listeners/Subjects

I'm not too sure how Java handles this with their Listener interfaces,
I can only think of having a listener/subject pair per event type and
then having something similar to the listener interfaces that Java has
by calling specific procedures in the interface'class from the
listener's update procedure.

So, there would possibly be 3 types: observer (abstract tagged),
subject (tagged), listener (interface). Then the control (e.g. a
window) would then have to implement an "Add_<whatever>_Listener" per
event type, which would add a <whatever>_Listener to a
<whatever>_Observer. Seems overly complex to me.

The one thing that Ada would have over the Java implementation is the
use of null subprograms in the interface, therefore an adapter type
would not be necessary as you would be able to implement only the
subprograms you are interested in.

Any comments would be welcome.

Thanks,
Luke.

Re: Event mechanisms for GUI's

[Jeffrey R. Carter]

Lucretia wrote:
> 
> I'm currently thinking of the event handling mechanism, I started to
> think about using the listener/subject pattern, but then started to
> wonder about the alternatives:

The best way is to have a protected event queue for each window. There 
should be mechanisms to specify what events are and are not put on the 
queue, and for combining the queues for multiple windows into one queue.

> This would be painful as there'd be a lot of case statements.

There's nothing wrong with case statements. They're very clear and easy 
to read and understand. Remember Ada's explicit design goal: "[E]mphasis 
was placed on program readability over ease of writing." [ARM 
Introduction] If you have a problem with writing case statements, then 
you probably haven't adopted The Ada Way yet.

-- 
Jeff Carter
"My mind is aglow with whirling, transient nodes of
thought, careening through a cosmic vapor of invention."
Blazing Saddles
85

Re: Event mechanisms for GUI's

[tmoran]

> There's nothing wrong with case statements. They're very clear and easy
In small quantity, yes.  But many-branched, nested, case statements with
a lot of near duplication are not so clear or maintainable.  They are
a very low abstraction level, computer-centric, device.
  If This_Window is for showing danger warnings in big red letters to the
reactor operator, and That_Window is for showing daily power demand over
the last month, a mouse click in either is similar from a computer-centric
view, but vastly different in the problem space.  Having This_Window_Type
objects and That_Window_Type objects as descendants of Basic_Window_Type
(inheriting what they have in common) makes them different objects, and a
dispatching call on When_Left_Button_Down(The_Clicked_Window) is in effect
a succinct abbreviation for a case statement on the type of Window,
implemented efficiently and without forgetfullness or typing errors,
automatically by the compiler.

Re: Event mechanisms for GUI's

[Jeffrey R. Carter]

tmoran@acm.org wrote:
>> There's nothing wrong with case statements. They're very clear and easy
> In small quantity, yes.  But many-branched, nested, case statements with
> a lot of near duplication are not so clear or maintainable.  They are
> a very low abstraction level, computer-centric, device.
>   If This_Window is for showing danger warnings in big red letters to the
> reactor operator, and That_Window is for showing daily power demand over
> the last month, a mouse click in either is similar from a computer-centric
> view, but vastly different in the problem space.  Having This_Window_Type
> objects and That_Window_Type objects as descendants of Basic_Window_Type
> (inheriting what they have in common) makes them different objects, and a
> dispatching call on When_Left_Button_Down(The_Clicked_Window) is in effect
> a succinct abbreviation for a case statement on the type of Window,
> implemented efficiently and without forgetfullness or typing errors,
> automatically by the compiler.

Sacrificing ease of reading for ease of writing.

-- 
Jeff Carter
"My mind is aglow with whirling, transient nodes of
thought, careening through a cosmic vapor of invention."
Blazing Saddles
85

Re: Event mechanisms for GUI's

[tmoran]

>> a succinct abbreviation for a case statement on the type of Window,
>>...
>Sacrificing ease of reading for ease of writing.
  I beg to differ.  It's the same abstraction argument that calls for
writing a subroutine even when said subroutine is only called one place.

Re: Event mechanisms for GUI's

[Jeffrey R. Carter]

tmoran@acm.org wrote:
>   I beg to differ.  It's the same abstraction argument that calls for
> writing a subroutine even when said subroutine is only called one place.

I beg to differ. When a subprogram is called from one place, it is clear 
when, why, and under what circumstance the call takes place. When a 
subprogram is passed to a windowing framework to be called when the 
framework pleases, it is much less clear.

-- 
Jeff Carter
"My mind is aglow with whirling, transient nodes of
thought, careening through a cosmic vapor of invention."
Blazing Saddles
85

Re: Event mechanisms for GUI's

[Lucretia]

Jeffrey R. Carter wrote:

> tmoran@acm.org wrote:
> >> There's nothing wrong with case statements. They're very clear and easy
> > In small quantity, yes.  But many-branched, nested, case statements with

[snip]

> > dispatching call on When_Left_Button_Down(The_Clicked_Window) is in effect
> > a succinct abbreviation for a case statement on the type of Window,
> > implemented efficiently and without forgetfullness or typing errors,
> > automatically by the compiler.
>
> Sacrificing ease of reading for ease of writing.

Well, this is actually another part of Ada's design, the ability to
write *correct* code, by using nested case/if statements can introduce
errors. That would be the wrong way to go.

Also, I'd like this not to go off-topic too early.

Thanks,
Luke.

Re: Event mechanisms for GUI's

[Dmitry A. Kazakov]

On 26 Sep 2006 10:28:04 -0700, Lucretia wrote:

[...]
> So, there would possibly be 3 types: observer (abstract tagged),
> subject (tagged), listener (interface). Then the control (e.g. a
> window) would then have to implement an "Add_<whatever>_Listener" per
> event type, which would add a <whatever>_Listener to a
> <whatever>_Observer. Seems overly complex to me.

The mechanisms themselves are not so important as composability of.
Messages are not, as Windows perfectly illustrates. Events are even less. 

And if publisher/subscriber looks too complex to you, then, well, the thing
you have described as complex is in fact just an oversimplification of what
really needed. Consider bidirectional publisher/subscriber relations, data
consistency, timing constraints issues, etc.

Also don't forget about clean separation of actions and notifications.
Button_Click vs. On_Button_Click. Hierarchy of events (Hover_Event vs.
Mouse_Move) and actions.

The bottom line, it is not simple.

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

Re: Event mechanisms for GUI's

[Jeffrey R. Carter]

Lucretia wrote:
> 
> Well, this is actually another part of Ada's design, the ability to
> write *correct* code, by using nested case/if statements can introduce
> errors. That would be the wrong way to go.

In most well designed systems, each case branch would contain a single 
statement. In any case, ease of reading is an important part of 
achieving correctness.

> Also, I'd like this not to go off-topic too early.

What mechanism provides the user with the clearest code, most control, 
and ease of use is, I thought, the topic.

-- 
Jeff Carter
"I like it when the support group complains that they have
insufficient data on mean time to repair bugs in Ada software."
Robert I. Eachus
91

Re: Event mechanisms for GUI's

[Randy Brukardt]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> wrote in message
news:D2CSg.992281$084.451732@attbi_s22...
> Lucretia wrote:
>...
> > Also, I'd like this not to go off-topic too early.
>
> What mechanism provides the user with the clearest code, most control,
> and ease of use is, I thought, the topic.

I would agree, but I certainly would disagree with your conclusions.

First of all, there is no simple or even satisfactory solution to this
problem. The trouble is that handling asynchronous events in a sequential
programming language (or even a high-level parallel one like Ada) is a poor
match. You complained about "a subprogram being called when a framework
pleases", but you have the same effect with any mechanism - the order of
operations depends on the events, not on the program. And any well-designed
framework will make it clear when subprograms will be called and by which
task.

Second, explicit event handling is among the worst solutions, because it
requires an explicit response to every possible event. A real GUI system
will have dozens, if not hundreds, of possible events for each Window. It's
easy to forget to handle some of those events; moreover any *explicit* code
necessary to do the *default* action reduces the readability of the system.
And the easiest solution (the others clause) completely eliminates the main
advantage of  using case statements -- the completeness check.

I'm not convinced that the "subprogram extension" solution used by Claw is
the best one, and I'm certainly not convinced that the multi-task
arrangement used by Claw is a good idea. (For a lot of systems, a single
task solution with an explicit call-me-now routine would be easier to work
with. But it would also make it a lot easier to starve the GUI - a problem
that explicit events certainly have as well.)

My final conclusion is that all of the solutions have severe trade-offs;
none is anywhere near optimal. My advice to the OP is to select a strategy
that works well for the problems that they want to solve, and not worry too
much about "goodness" -- it's not going to happen in a GUI (that's why GUI
builders are so indispensable).

                            Randy.
.

Re: Event mechanisms for GUI's

[Jeffrey R. Carter]

Randy Brukardt wrote:
> 
> I would agree, but I certainly would disagree with your conclusions.

That's OK. I'm aware that my views on such things as SW design and 
language design are not widely shared. Perhaps someone can show me that 
I'm wrong. That's one way to learn.

> First of all, there is no simple or even satisfactory solution to this
> problem. The trouble is that handling asynchronous events in a sequential
> programming language (or even a high-level parallel one like Ada) is a poor
> match. You complained about "a subprogram being called when a framework
> pleases", but you have the same effect with any mechanism - the order of
> operations depends on the events, not on the program. And any well-designed
> framework will make it clear when subprograms will be called and by which
> task.

With configurable event queues, the user decides when events will be 
processed. With a callback mechanism, the framework makes those decisions.

> Second, explicit event handling is among the worst solutions, because it
> requires an explicit response to every possible event. A real GUI system
> will have dozens, if not hundreds, of possible events for each Window. It's
> easy to forget to handle some of those events; moreover any *explicit* code
> necessary to do the *default* action reduces the readability of the system.
> And the easiest solution (the others clause) completely eliminates the main
> advantage of  using case statements -- the completeness check.

As I said, which events are and are not put on the queues should be 
configurable, and multiple queues should be able to be merged into one. 
An application which needs every possible event put on the queue will be 
quite rare.

There will still need to be an others clause (for all those possible 
events that will not be put on the queue). It should raise an exception. 
If you forget to handle an event that you've specified should be put on 
the queue, that should alert you to the lack of completeness.

> My final conclusion is that all of the solutions have severe trade-offs;
> none is anywhere near optimal. My advice to the OP is to select a strategy
> that works well for the problems that they want to solve, and not worry too
> much about "goodness" -- it's not going to happen in a GUI (that's why GUI
> builders are so indispensable).

I've used callback, dispatching, and event-queue GUIs, and I prefer the 
latter. The code is much clearer.

-- 
Jeff Carter
"I like it when the support group complains that they have
insufficient data on mean time to repair bugs in Ada software."
Robert I. Eachus
91

Re: Event mechanisms for GUI's

[tmoran]

>I've used callback, dispatching, and event-queue GUIs, and I prefer the
  Of course given a callback or dispatching base framework, the called
routine could just inject an "event" into a custom event-queue framework.

Re: Event mechanisms for GUI's

[Randy Brukardt]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> wrote in message
news:_AHSg.210879$1i1.191702@attbi_s72...
> Randy Brukardt wrote:
...
> > First of all, there is no simple or even satisfactory solution to this
> > problem. The trouble is that handling asynchronous events in a
sequential
> > programming language (or even a high-level parallel one like Ada) is a
poor
> > match. You complained about "a subprogram being called when a framework
> > pleases", but you have the same effect with any mechanism - the order of
> > operations depends on the events, not on the program. And any
well-designed
> > framework will make it clear when subprograms will be called and by
which
> > task.
>
> With configurable event queues, the user decides when events will be
> processed. With a callback mechanism, the framework makes those decisions.

That's *usually* a good thing -- it hides a lot of irrelevant detail from
the user, so they can concentrate on the important things. After all, 99% of
the time, you simply want to handle menu selections -- you don't care how
those are done. Yes, there is that 1% that might be harder, but I'm really
dubious that there is any one-size-fits-all solution.

...
> > My final conclusion is that all of the solutions have severe trade-offs;
> > none is anywhere near optimal. My advice to the OP is to select a
strategy
> > that works well for the problems that they want to solve, and not worry
too
> > much about "goodness" -- it's not going to happen in a GUI (that's why
GUI
> > builders are so indispensable).
>
> I've used callback, dispatching, and event-queue GUIs, and I prefer the
> latter. The code is much clearer.

My experience with Windows message loop (which is just a poorly implemented
event queue) using our old Win32 binding (which covered up the ugly stuff)
was that short programs were easier to write and understand, but that it
didn't scale well. And reuse was near impossible; that's easy for the tagged
dispatching version. OTOH, the dispatching version requires writing a type
and a bunch of subprograms for typical simple uses -- which is annoying. So
I think it is a case of many trade-offs, but no solution that is clearly
better.

                                      Randy.

Re: Event mechanisms for GUI's

[Lucretia]

> With configurable event queues, the user decides when events will be
> processed. With a callback mechanism, the framework makes those decisions.

I'm not sure what you mean by these "configurable event queues," do you
have any examples or know of a toolkit that has documentation online
which uses them that I can look at?

Thanks,
Luke.

Re: Event mechanisms for GUI's

[Lucretia]

> And the easiest solution (the others clause) completely eliminates the main
> advantage of  using case statements -- the completeness check.

You can implement a listener like mechanism which can have this
completeness check, you make all operations abstract and the compiler
will complain about missing primitives. The problem here is that you
are forcing the developer to implement primitives that they do not want
and which will most likely end up being null primitives anyway. So this
isn't really a good argument. The developer will only want to know
about certain events, not all of them.

Thanks,
Luke.

Re: Event mechanisms for GUI's

[Jeffrey R. Carter]

Lucretia wrote:
> 
> I'm not sure what you mean by these "configurable event queues," do you
> have any examples or know of a toolkit that has documentation online
> which uses them that I can look at?

I don't know of any GUI framework that has them. They're part of my idea 
of the ideal GUI I/F. Each top level window has a protected event queue; 
the queues for multiple windows may be combined. Which events are 
actually put in the queue is configurable by the user.

-- 
Jeff Carter
"Why don't you bore a hole in yourself and let the sap run out?"
Horse Feathers
49

Re: Event mechanisms for GUI's

[Lucretia]

On Oct 15, 2:22 am, "Jeffrey R. Carter"
<spam.not.jrcar...@acm.not.spam.org> wrote:
> Lucretia wrote:
>
> > I'm not sure what you mean by these "configurable event queues," do you
> > have any examples or know of a toolkit that has documentation online
> > which uses them that I can look at?I don't know of any GUI framework that has them. They're part of my idea
> of the ideal GUI I/F. Each top level window has a protected event queue;
> the queues for multiple windows may be combined. Which events are
> actually put in the queue is configurable by the user.

So, on creation you specify which events you want via some sort of
bitmask?

Luke.

Re: Event mechanisms for GUI's

[Ed Falis]

Jeffrey R. Carter wrote:

> I don't know of any GUI framework that has them. They're part of my
> idea
> of the ideal GUI I/F. Each top level window has a protected event
> queue;
> the queues for multiple windows may be combined. Which events are
> actually put in the queue is configurable by the user.
>

Not sure I fully understand what you mean by configurable message
queues, but the model sounds similar to the BeOS/Haiku/Zeta approach
described at
http://beunited.org/bebook/The%20Application%20Kit/topic_Messaging.html

What do you think?

Re: Event mechanisms for GUI's

[Jeffrey R. Carter]

Lucretia wrote:
> 
> So, on creation you specify which events you want via some sort of
> bitmask?

I would think there would be a default set, to which you could add or 
subtract events or sets of events, as well as specifying a complete set 
of events.

-- 
Jeff Carter
"I would never want to belong to any club that
would have someone like me for a member."
Annie Hall
41

Re: Event mechanisms for GUI's

[Jeffrey R. Carter]

Ed Falis wrote:
> 
> Not sure I fully understand what you mean by configurable message
> queues, but the model sounds similar to the BeOS/Haiku/Zeta approach
> described at
> http://beunited.org/bebook/The%20Application%20Kit/topic_Messaging.html
> 
> What do you think?

Underneath it may have have a similar model, but its main thrust seems 
to be similar to registering callbacks (BHandler) and giving up control 
to a main loop (BLooper) in many GUI frameworks.

-- 
Jeff Carter
"I would never want to belong to any club that
would have someone like me for a member."
Annie Hall
41

Re: Event mechanisms for GUI's

[Lucretia]

On Oct 16, 5:11 am, "Jeffrey R. Carter"
<spam.not.jrcar...@acm.not.spam.org> wrote:
> Lucretia wrote:
>
> > So, on creation you specify which events you want via some sort of
> > bitmask?I would think there would be a default set, to which you could add or
> subtract events or sets of events, as well as specifying a complete set
> of events.

The only way I can see of doing this (unless you want to supply some
code to illustrate) is by providing the listener idiom and separating
each listener "handler" into a separate interfaces (Ada 2005) and then
providing a Set_Events_Mask on the component which goes through the bit
mask and checks if there are interfaces set for the particular events:

package Button_Up_Listeners is

  type Button_Up_Listener is interface;

  procedure Button_Up(Component : in Button; Event : in Button_Event);

end Button_Up_Listeners;


package Button_Down_Listeners is

  type Button_Down_Listener is interface;

  procedure Button_Down(Component : in Button; Event : in
Button_Event);

end Button_Down_Listeners;


package Buttons is

  type Button_Events_Mask is (Up, Down, Double_Click, ...);
  for Button_Events_Mask use ...;

  Button_Events_Mask_Error : exception;

  type Button is new Control with private;

  procedure Set_Button_Up_LIstener(Self : in out Button; Listener : in
Button_Up_Listener);
  procedure Set_Button_Down_LIstener(Self : in out Button; Listener :
in Button_Down_Listener);

  -- This raises Button_Events_Mask_Error
  procedure Set_Bit_Mask(Self : in out Button; Mask : in
Button_Events_Mask);

end Buttons;

package My_Button_Listeners is

  type My_Button_Listener is Button_Up_Listener and
Button_Down_Listener;

  ...

end My_Button_Listeners;


procedure Test_Button is

  My_Button : Button;

begin

  My_Button.Set_Button_Up_LIstener(My_Button_Listener);
  My_Button.Set_Bit_Mask(Up or Down); -- raises exception!

end Test_Button;

But there are problems with this:

1) use of multiple interfaces just to provide 1 "event handler" over
the use of 1 listener interface which provides all "event handlers"
which are specified as null procedures so that the user can override
the ones (s)he is interested in.

2) the user may forget to do the test (the Set_Bit_Mask call).

Thanks,
Luke.

Re: Event mechanisms for GUI's

[Dmitry A. Kazakov]

On 19 Oct 2006 07:22:09 -0700, Lucretia wrote:

> But there are problems with this:
> 
> 1) use of multiple interfaces just to provide 1 "event handler" over
> the use of 1 listener interface which provides all "event handlers"
> which are specified as null procedures so that the user can override
> the ones (s)he is interested in.
> 
> 2) the user may forget to do the test (the Set_Bit_Mask call).

3) You cannot provide a default implementation for events, when those
handlers are interfaces.

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

Re: Event mechanisms for GUI's

[Jeffrey R. Carter]

Lucretia wrote:
> 
> The only way I can see of doing this (unless you want to supply some
> code to illustrate) is by providing the listener idiom and separating
> each listener "handler" into a separate interfaces (Ada 2005) and then
> providing a Set_Events_Mask on the component which goes through the bit
> mask and checks if there are interfaces set for the particular events:

That seems overly complicated. Something like

type Window_ID is ...;

type Widget_ID is ...;

type Event_ID is
    (Close, Left_Click, Middle_Click, Right_Click, Double_Click, ...);

type Event_List is array (Positive range <>) of Event_ID;

type Event_Set is private;

function Make (List : Event_List) return Event_Set;

procedure Add (To : in Window_ID; Event : in Event_ID);
procedure Remove (From : in Window_ID; Event : in Event_ID);

procedure Add (To : in Window_ID; Set : in Event_Set);
procedure Remove (From : in Window_ID; Set : in Event_Set);

function Event_Pending (Window : Window_ID) return Boolean;
procedure Get (Event : out Event_ID; Widget : out Widget_ID);

-- 
Jeff Carter
"I fart in your general direction."
Monty Python & the Holy Grail
05

Re: Event mechanisms for GUI's

[Lucretia]

On Oct 19, 9:18 pm, "Jeffrey R. Carter"
<spam.not.jrcar...@acm.not.spam.org> wrote:
>>That seems overly complicated. Something like
>
> type Window_ID is ...;
>
> type Widget_ID is ...;
>
> type Event_ID is
>     (Close, Left_Click, Middle_Click, Right_Click, Double_Click, ...);
>
> type Event_List is array (Positive range <>) of Event_ID;
>
> type Event_Set is private;
>
> function Make (List : Event_List) return Event_Set;
>
> procedure Add (To : in Window_ID; Event : in Event_ID);
> procedure Remove (From : in Window_ID; Event : in Event_ID);
>
> procedure Add (To : in Window_ID; Set : in Event_Set);
> procedure Remove (From : in Window_ID; Set : in Event_Set);
>
> function Event_Pending (Window : Window_ID) return Boolean;
> procedure Get (Event : out Event_ID; Widget : out Widget_ID);

What exactly are you adding or removing from the window_id?

This also seems a bit more procedural, rather than using the more
natural OO way. Remember, in Ada you use what applies and is more
natural, a GUI is inherently OO.

Thanks,.
Luke.

Re: Event mechanisms for GUI's

[Lucretia]

>What exactly are you adding or removing from the window_id?

Ok, I see what you're adding to the window.

> This also seems a bit more procedural, rather than using the more
> natural OO way. Remember, in Ada you use what applies and is more
> natural, a GUI is inherently OO.

I think this tho ;-D.

Luke.

Re: Event mechanisms for GUI's

[Jeffrey R. Carter]

Lucretia wrote:
> 
> This also seems a bit more procedural, rather than using the more
> natural OO way. Remember, in Ada you use what applies and is more
> natural, a GUI is inherently OO.

OO is a design attribute. It has nothing to do with the language 
mechanisms used to implement the design. The implementation technique 
usually called OOP is actually programming by extension.

While extending windows might make sense, I see no use to extending 
events or event queues.

-- 
Jeff Carter
"I fart in your general direction."
Monty Python & the Holy Grail
05