* Event mechanisms for GUI's
@ 2006-09-26 17:28 Lucretia
2006-09-26 20:39 ` Jeffrey R. Carter
2006-09-27 8:10 ` Dmitry A. Kazakov
0 siblings, 2 replies; 26+ messages in thread
From: Lucretia @ 2006-09-26 17:28 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-09-26 17:28 Event mechanisms for GUI's Lucretia
@ 2006-09-26 20:39 ` Jeffrey R. Carter
2006-09-26 23:18 ` tmoran
2006-09-27 8:10 ` Dmitry A. Kazakov
1 sibling, 1 reply; 26+ messages in thread
From: Jeffrey R. Carter @ 2006-09-26 20:39 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-09-26 20:39 ` Jeffrey R. Carter
@ 2006-09-26 23:18 ` tmoran
2006-09-27 3:02 ` Jeffrey R. Carter
0 siblings, 1 reply; 26+ messages in thread
From: tmoran @ 2006-09-26 23:18 UTC (permalink / raw)
> 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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-09-26 23:18 ` tmoran
@ 2006-09-27 3:02 ` Jeffrey R. Carter
2006-09-27 4:26 ` tmoran
2006-09-27 6:21 ` Lucretia
0 siblings, 2 replies; 26+ messages in thread
From: Jeffrey R. Carter @ 2006-09-27 3:02 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-09-27 3:02 ` Jeffrey R. Carter
@ 2006-09-27 4:26 ` tmoran
2006-09-27 5:39 ` Jeffrey R. Carter
2006-09-27 6:21 ` Lucretia
1 sibling, 1 reply; 26+ messages in thread
From: tmoran @ 2006-09-27 4:26 UTC (permalink / raw)
>> 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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-09-27 4:26 ` tmoran
@ 2006-09-27 5:39 ` Jeffrey R. Carter
0 siblings, 0 replies; 26+ messages in thread
From: Jeffrey R. Carter @ 2006-09-27 5:39 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-09-27 3:02 ` Jeffrey R. Carter
2006-09-27 4:26 ` tmoran
@ 2006-09-27 6:21 ` Lucretia
2006-09-27 21:29 ` Jeffrey R. Carter
1 sibling, 1 reply; 26+ messages in thread
From: Lucretia @ 2006-09-27 6:21 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-09-26 17:28 Event mechanisms for GUI's Lucretia
2006-09-26 20:39 ` Jeffrey R. Carter
@ 2006-09-27 8:10 ` Dmitry A. Kazakov
1 sibling, 0 replies; 26+ messages in thread
From: Dmitry A. Kazakov @ 2006-09-27 8:10 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-09-27 6:21 ` Lucretia
@ 2006-09-27 21:29 ` Jeffrey R. Carter
2006-09-27 23:05 ` Randy Brukardt
0 siblings, 1 reply; 26+ messages in thread
From: Jeffrey R. Carter @ 2006-09-27 21:29 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-09-27 21:29 ` Jeffrey R. Carter
@ 2006-09-27 23:05 ` Randy Brukardt
2006-09-28 3:47 ` Jeffrey R. Carter
2006-10-14 19:44 ` Lucretia
0 siblings, 2 replies; 26+ messages in thread
From: Randy Brukardt @ 2006-09-27 23:05 UTC (permalink / raw)
"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.
.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-09-27 23:05 ` Randy Brukardt
@ 2006-09-28 3:47 ` Jeffrey R. Carter
2006-09-28 4:15 ` tmoran
` (2 more replies)
2006-10-14 19:44 ` Lucretia
1 sibling, 3 replies; 26+ messages in thread
From: Jeffrey R. Carter @ 2006-09-28 3:47 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-09-28 3:47 ` Jeffrey R. Carter
@ 2006-09-28 4:15 ` tmoran
2006-09-29 3:16 ` Randy Brukardt
2006-10-14 19:25 ` Lucretia
2 siblings, 0 replies; 26+ messages in thread
From: tmoran @ 2006-09-28 4:15 UTC (permalink / raw)
>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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-09-28 3:47 ` Jeffrey R. Carter
2006-09-28 4:15 ` tmoran
@ 2006-09-29 3:16 ` Randy Brukardt
2006-10-14 19:25 ` Lucretia
2 siblings, 0 replies; 26+ messages in thread
From: Randy Brukardt @ 2006-09-29 3:16 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-09-28 3:47 ` Jeffrey R. Carter
2006-09-28 4:15 ` tmoran
2006-09-29 3:16 ` Randy Brukardt
@ 2006-10-14 19:25 ` Lucretia
2006-10-15 1:22 ` Jeffrey R. Carter
2 siblings, 1 reply; 26+ messages in thread
From: Lucretia @ 2006-10-14 19:25 UTC (permalink / raw)
> 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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-09-27 23:05 ` Randy Brukardt
2006-09-28 3:47 ` Jeffrey R. Carter
@ 2006-10-14 19:44 ` Lucretia
1 sibling, 0 replies; 26+ messages in thread
From: Lucretia @ 2006-10-14 19:44 UTC (permalink / raw)
> 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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-10-14 19:25 ` Lucretia
@ 2006-10-15 1:22 ` Jeffrey R. Carter
2006-10-15 2:29 ` Lucretia
2006-10-15 13:53 ` Ed Falis
0 siblings, 2 replies; 26+ messages in thread
From: Jeffrey R. Carter @ 2006-10-15 1:22 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-10-15 1:22 ` Jeffrey R. Carter
@ 2006-10-15 2:29 ` Lucretia
2006-10-16 4:11 ` Jeffrey R. Carter
2006-10-15 13:53 ` Ed Falis
1 sibling, 1 reply; 26+ messages in thread
From: Lucretia @ 2006-10-15 2:29 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-10-15 1:22 ` Jeffrey R. Carter
2006-10-15 2:29 ` Lucretia
@ 2006-10-15 13:53 ` Ed Falis
2006-10-16 4:19 ` Jeffrey R. Carter
1 sibling, 1 reply; 26+ messages in thread
From: Ed Falis @ 2006-10-15 13:53 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-10-15 2:29 ` Lucretia
@ 2006-10-16 4:11 ` Jeffrey R. Carter
2006-10-19 14:22 ` Lucretia
0 siblings, 1 reply; 26+ messages in thread
From: Jeffrey R. Carter @ 2006-10-16 4:11 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-10-15 13:53 ` Ed Falis
@ 2006-10-16 4:19 ` Jeffrey R. Carter
0 siblings, 0 replies; 26+ messages in thread
From: Jeffrey R. Carter @ 2006-10-16 4:19 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-10-16 4:11 ` Jeffrey R. Carter
@ 2006-10-19 14:22 ` Lucretia
2006-10-19 15:04 ` Dmitry A. Kazakov
2006-10-19 20:18 ` Jeffrey R. Carter
0 siblings, 2 replies; 26+ messages in thread
From: Lucretia @ 2006-10-19 14:22 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-10-19 14:22 ` Lucretia
@ 2006-10-19 15:04 ` Dmitry A. Kazakov
2006-10-19 20:18 ` Jeffrey R. Carter
1 sibling, 0 replies; 26+ messages in thread
From: Dmitry A. Kazakov @ 2006-10-19 15:04 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-10-19 14:22 ` Lucretia
2006-10-19 15:04 ` Dmitry A. Kazakov
@ 2006-10-19 20:18 ` Jeffrey R. Carter
2006-10-19 21:51 ` Lucretia
1 sibling, 1 reply; 26+ messages in thread
From: Jeffrey R. Carter @ 2006-10-19 20:18 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-10-19 20:18 ` Jeffrey R. Carter
@ 2006-10-19 21:51 ` Lucretia
2006-10-19 22:01 ` Lucretia
2006-10-20 4:48 ` Jeffrey R. Carter
0 siblings, 2 replies; 26+ messages in thread
From: Lucretia @ 2006-10-19 21:51 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-10-19 21:51 ` Lucretia
@ 2006-10-19 22:01 ` Lucretia
2006-10-20 4:48 ` Jeffrey R. Carter
1 sibling, 0 replies; 26+ messages in thread
From: Lucretia @ 2006-10-19 22:01 UTC (permalink / raw)
>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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Event mechanisms for GUI's
2006-10-19 21:51 ` Lucretia
2006-10-19 22:01 ` Lucretia
@ 2006-10-20 4:48 ` Jeffrey R. Carter
1 sibling, 0 replies; 26+ messages in thread
From: Jeffrey R. Carter @ 2006-10-20 4:48 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2006-10-20 4:48 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-09-26 17:28 Event mechanisms for GUI's Lucretia
2006-09-26 20:39 ` Jeffrey R. Carter
2006-09-26 23:18 ` tmoran
2006-09-27 3:02 ` Jeffrey R. Carter
2006-09-27 4:26 ` tmoran
2006-09-27 5:39 ` Jeffrey R. Carter
2006-09-27 6:21 ` Lucretia
2006-09-27 21:29 ` Jeffrey R. Carter
2006-09-27 23:05 ` Randy Brukardt
2006-09-28 3:47 ` Jeffrey R. Carter
2006-09-28 4:15 ` tmoran
2006-09-29 3:16 ` Randy Brukardt
2006-10-14 19:25 ` Lucretia
2006-10-15 1:22 ` Jeffrey R. Carter
2006-10-15 2:29 ` Lucretia
2006-10-16 4:11 ` Jeffrey R. Carter
2006-10-19 14:22 ` Lucretia
2006-10-19 15:04 ` Dmitry A. Kazakov
2006-10-19 20:18 ` Jeffrey R. Carter
2006-10-19 21:51 ` Lucretia
2006-10-19 22:01 ` Lucretia
2006-10-20 4:48 ` Jeffrey R. Carter
2006-10-15 13:53 ` Ed Falis
2006-10-16 4:19 ` Jeffrey R. Carter
2006-10-14 19:44 ` Lucretia
2006-09-27 8:10 ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox