World: r3wp

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

I'm late and give my vote to #2.

Why ? because I think it's the easiest way to assemble components 
containing several gobs acting together.

easiest way meaning: less code

On the contrary of what other believe, I tink the most common case, 
is to propagate events

I take one example:

If I create one button style with only one gob and then I decide 
to add an inner gob to change its aspect.
I don't want to have to change some code just because of that.
Gob's compositing  should be the easiest as possible

If there is design tension between what is easier for the style developer 
versus the style user, my vote is to favor the style user because 
styles are used far more often than they are built.

It's a good point though Steeve.

Any news from RMA guys? Not trying to push for anything, just curious 
about the progress of the GUI implementation. Acutally I do remember 
you stating you are taking longer time before there is next relase. 
So how things go?

Quite good. We did some major re-factoring and are currently getting 
automatic GUI testing done. We need this for several reasons:
1. Automatic style lib testing
2. Applicaiton testing

This is a major step as it will reduce our hours to do these tasks. 
Testability must be designed in right from the start and it will 
save thousands of hours of effort later.

Sounds very encouraging Robert.

As for the "event bubbling", I too agree, that Steeve has some merit 
here, although I voted differently :-(

Robert - interesting. How goes redesign of "vid level" actions/reactions?

This is already done.

Thanks for the report Robert!

A post to keep you informed about what the ELICA LOGO can do relative 
to 3D graphics, animation an GUI (under windows only) - all their 
libraries are open source and I thought you would like to know about 
- see the link in the OPEN GL group. Hope it can be useful in some 
way or another. Regards, Gerard

Thery are also developing a compatibler ELICA LOGO compiler called 
Lhogho. refs are also included.

Has there been any recent releases here?

Still into deep rewrites.