World: r3wp

Just supppoting question - in R2 we were able to have "event filters" 
defined via insert-event-func. It allowed us to catch events going 
to subfaces. So my question is - if e.g. for #1, the event goes directly 
to face B, am I able to catch it, by inserting the filter into face 
A?

http://www.rebol.com/docs/view-face-events.html#section-14

I wonder if anyone uses reverse aproach - from top window, down to 
bottom face. Would be slow probably?

I do remember how QNX Photon used such a trick to share screen content. 
You defined X*Y area of the screen (imagine empty translucent face) 
and all events got via that "filter", so that you know what to send 
to target computer, and then the event was propagated to cause an 
action (at least that is how I understood it back then)

Hmm, I wonder if my Photon example is in contradition or in any relation, 
as having translucent face upon A->B does not make A->B being child 
of such a filter face ...

I am probably for #3 or #1. Just help me to brainstorm one case - 
what we have mostly wrong in REBOL, is pop-up handling. I mean - 
just recently e.g. when you "drag", and you move away from the face 
coordinates, the dragging stops. The same goes for the context menu 
etc - you have to be able to close the menu by clicking anywhere 
in the apps window. Which model fits best?

One of the attractions of #1 is that it makes it easy to implement 
"default handlers" at some point higher up the hierarchy. For example 
based upon an  "esc pressed event" (if one were to exist.) and you 
had designed a panel with four buttons. If you wanted to close the 
panel when the user pressed esc, you would simply have a single "handler" 
for the panel which would receive the event.


I'm sure that this isn't  the best example and apologise in advance 
for my ignorance of REBOL3-GUI and its common terms.

Perhaps a better example would be to allow a user to tab along a 
row of buttons. A single handler could be written for the button 
"container" that would handle tab presses instead of each button 
having a specific "handler".

With 3. you can simulate 1. The advantage of 3. is, that I can decide 
at what place the parent actor is called.


Which leads me to a question: Is 3. a call the parent actor, which 
returns, or do I just let the event flow and it will never return 
to my handler?

On the other hand with #3, this could be achieved by the buttons 
sharing a single event handler function.


The clairty that option #3 brings in that as you always have to specify 
what happens to an event would, for me, lead to a lower number of 
"head scratching" bugs.

Yes, 3. is explicit while 1. is implicit.

I prefer #1 and then #3.

Is there a way that we can use #1 and add a way that it can be overriden 
by #3 concept? So, everyone how don't require fine-grained handling, 
uses default bubbeling.

If bubbling is enabled by default, you just need to add an actor 
where you want to catch the event.

For example if I add image to button, with #3 I need to ad actor 
to image to catch click and send it to button. With #1 it's done 
automatically.

Rebolek, wht you mean by 'add image to button'?

So far it looks everyone is happy with the current behaviour (#3)?

It's just an example, image you want to add save icon to save button.

So can I translate as 'Image face inside Button face'?

exactly.

If yes, then in #1 case the event would be processed in the Image 
as well because image style have defined on-click actor no?

...and currently you cannot set actor to undefined state. So #1 wouldn't 
be too much useful, isn't it?

as I said, it's just an example

yes, I'm just trying to see what could be better on the #1

Personally I prefer also the  the current #3 behaviour but if we 
want to deal with more complex propagation I'd go with the #2 which 
gives really flexible control for some special cases but  as some 
of you noted it will be complex for event handling of the rest 95% 
of normal cases.

is there any issue in propagating a larger number of different events? 
suppose you want to simply handle all events from an inside face.

When thinking  #3 vs. #1:

In the #3 case the propagation should be done like:

on-click: [
	all [
		pf: parent-face? face
		do-actor pf 'on-click arg
	]
]


the code above would pass the received event in ARG value to the 
ON-CLICK actor of the parent face.


The #1 option would offer probably simpler shortcut to propagate 
the event up like:

on-click: none

but we would need to allow write in the dialect something like:

view [
	hpanel [
		box red on-click [print "red box clicked"]
		box blue on-click none
	] on-click [print "panel clicked"]
]


in the code above the ON-CLICK actor of blue box face could be set 
to NONE to allow propagate the click event up so the ON-CLICK actor 
of hpanel is executed.

Henrik, I think propagating large number of events is solved easily 
using the #2 as this is some kind of special case imo. normally you 
don't need to propagate even't too much. That's why others doesn't 
like the #2 option much imo.

ok, I think I got it a bit backwards, so maybe #3 is OK.

I don't like the idea in #1 that an outer ON-CLICK overwrites an 
inner ON-CLICK in case the inner ON-CLICK is very complex.

The #1 is IMO very simmilar to #4..it differs just by the form of 
the syntax:

#1 example:

view [
	hpanel [
		box red on-click [print "red box clicked"]
		box blue on-click none
	] on-click [print "panel clicked"]
]

#4 example:

view [
	hpanel [
		box red on-click [print "red box clicked"]
		box blue options: [propagate-actors: [on-click]]
	] on-click [print "panel clicked"]
]

Henrik, "in case the inner ON-CLICK is very complex" what you mean 
by this? The inner ON-CLICK just doesn't have to be defined, not 
complex if you want to execute the outer one no?

Otherwise in the #1 case I can image there could be some confusing 
situations where some face doesn't have some actor defined and the 
event will 'bubble' too much up in the face structure causing execution 
of unwanted actor. What do you think?

image=imagine

I think if such confusing situation will happen, it's solely style's 
writer responsibility.

So maybe th #3 is really best default behaviour that keeps events 
under control. I agree here that in case of #3, if you want to propagate 
event's then you would need to write more code that you would like 
though but  OTOH you know what you are doing.

Cyphre, I was supposing that this would be the same for style content 
as well as for layouts. Hard to explain without a deeper study of 
all the mechanics of how events are propagated or overwritten.

For style content you would use standard styles that may have complex 
event handlers. You likely don't want to overwrite those.

Rebolek, that's not true. You can create layouts with misc actors 
combinations that will behave strange and you'll be scratching your 
head where to put at least empty actor to stop the unvantred propagation.

As for overriding. I am not sure higher level on-click should disable 
lower level on-click. In the OOP I used (CA-Visual Objects), and 
just IIRC (so sorry, if inaccurate), you had such options:

- to execute child method

- in the above you either returned false (maybe I get this one wrong, 
but you get the idea) or the parent method was called right after 
the child's method 

- there was also some override option, but I don't remember it, it 
is 12 years old experience

Cyphre: if we go for #3, will there be the option to "insert-event-func" 
like in R2 ('detect functionality), which would allow us to apply 
some filters? E.g. for dev/demo purposes?

Rebolek, also I'm afraid in case of #1....since you can call any 
actor of any style/face from the style code, we would propbably check 
all such DO-ACTOR calls in the code to make sure they are not called 
on style/face that doesn't have the specific actor defined othervise 
the propagation would be triggered.

Pekr, I don't think 'insert-event-func' has anything to do with this 
decission. Currently R3GUI doesn't have the exact 'insert-event-func' 
mechanism. But you can add your custom handler with specific priority 
into the main event loop and then either filter out or pass the events 
to the system.

(this feature is imo more flexible than the 'insert-event-func' stuff 
in R2)

I never liked insert-event-func very much.

Given Richard's example, where unhandled events bubble:

view [
	hpanel [
		box red on-click [print "red box clicked"]
		box blue on-click none
	] on-click [print "panel clicked"]
]

box blue on-click none

 had hidden meaning. It means "pass thru", not "don't take action". 
 Give his example of how to explicitly propagate events:

on-click: [
	all [
		pf: parent-face? face
		do-actor pf 'on-click arg
	]
]


Would it be possible to define a shortcut, e.g. on-click 'pass-thru, 
in either scenario?

the "it will be complex for event handling of the rest 95% of normal 
cases" is the reason why I prefer #3. As Gregg noted, in case of 
having #3 we can still define some "shortcuts" either by defining 
a simple actor "propagating" some event, or even adjust the layout 
dialect to accept a keyword

(a simple actor "propagating" some event up the parent hierarchy 
can be easily inherited)

Gregg, Ladislav: ye, I agree, so to me it looks the 'conclusion' 
is heading to the #3 case with some possible 'shortcut' support to 
make the event propagation less verbal for the programmer. What do 
you think? Should we wait for more input or close this topic?

most flexible option is the preferred for me

Close the topic, Cyphre - your conclusion seems about to be right 
.....