World: r3wp

Also - DO is an implicit REACTOR, but still one of reactors. So - 
what will happen to DO itself? Will we call it just another KEYWORD?

button "browse" on-click [browse http://rm-asset.com]

than you can use things like: on-hoover, etc. too

well, so you are basically exposing low level actors to the dialect 
level. Initial idea was to have hidden actions inside the style level. 
What you propose might work, but how do I set an action? Can I somehow 
 "chain" actions?

button "browse" on-hoover [code here] on-click [code here]?


Also - does not it make dialect more complicated? You have to count 
on every possible action any style can have ....

chain: Yes, why not.

complicated: No, it get clearer. The current system is complicated 
if you want to do more than kid things. That was the same problem 
with VID. It was simple for non-value things but not flexible for 
enterprise things.

the problem with complexity is, you can't get rid of it. Only complicated 
things can be reduced.

Well, VID was always declarative, and we know it was/is limited. 
From your proposal it still looks good to me, there just will be 
the need to be able to specify more then one action. I can even imagine:

button "browse" #"B" action [
    on-click [do something]
    on-hover [do something]
]


But for single actions, there would be one unnecessary block level 
probably. I am open to any proposals, and looking forward to final 
solution ....

it won't be necessary with actions (I hope). you simply call actors 
directly. About chaining them, how does it make sense to chain an 
on-click and on-hover actor? They are separate actions. What you 
need is the ability to stack the action code for actors, so that 
if an actor is already defined for a style, then the new action code 
could be appended to the original code. I use a similar design in 
my private version of the VID Extension Kit, but am also forced to 
use the traditional actions as they are part of the standard face.

stacking, chaining - whatever. We just need to be able to specify 
more than one action, that's all ...

if you can't, then the GUI will be entirely useless. you couldn't 
even start it.

What you are basically doing is some OOP aproach here. But adding 
the code to the end? Who decided that? There are three levels - replace 
action, pre-init, post-init. So what do we choose? In Visual Objects 
I had all three capabilities. Dunno if you would find that usefull 
though ....

I'm not sure it will be implemented that way, but it is already a 
problem that we need to append actor code to a previous actor, when 
creating a new style, based on an older one. An example of this is 
a field with extra functionality to perform some kind of action on 
an attached face in the ON-KEY actor. This is possible now, but the 
method is obscure.

A terminology problem related to the ATTACH keyword. Every face should 
have an attribute listing the items attached to it, and an attribute 
listing the items to which it was attached. One (let's call it 'extra 
long') alternative might be ITEMS-ATTACHED-TO-THIS and ITEMS-TO-WHICH-THIS-IS-ATTACHED. 
To show you an example, let's have faces A and B, and suppose, that 
the user attached B to A. Then:

1) for A, the ITEMS-ATTACHED-TO-THIS list shall contain B
2) for B, the ITEMS-TO-WHICH-THIS-WAS-ATTACHED shall contain A


The problem is, that the above two attribute names probably aren't 
the best possible (or, are they?). Any "ideal" attribute names you 
prefer?

Well, this is really a bit longish :-) Having fever, it is a bit 
difficult to think for me, but :-):

1) ATTACHED
2) ATTACHING

Hmm,not clear after few secs .... so:

1) ATTACHED-FROM
2) ATTACHING-TO

?

I am not sure it is correct english wise though ...

My understanding is that the purpose of ATTACH is to direct the flow 
of action events.....


....If face B is attached to face C, then face C also gets B's action 
events. And if B is attached to A, then B gets A's action events, 
prior to them flowing to C.


So, from a stream-of-events, perspective: A is UPSTREAM of B. While 
C is DOWNSTREAM of B.


Hence a suggestion,,,,,, ATTACHED-UPSTREAM and ATTACHED-DOWNSTREAM.

there is also an alternative world to ATTACH - CONNECT?

Sunanda - nice suggestion ....

parent-faces child-faces

or similar

It is possible, I think, Graham that a face can be in more than one 
heirarchy; so PARENT and CHILD alone does not describe which hierarchy.

Other structures that may have child/parent faces: panels within 
panels; Z-axis visibility.

Ok, change that to parents-faces

These are like linked lists where elements might be in one than one 
list?

IS-ATTACHED / HAVE-ATTACH

It's time to decide about propagation of events using actors in R3GUI 
so we would like to know your opinion on that.

example:
Let's have face A and face B which is inside face A.

Currently, when you click mouse button on the face B and the face 
B has defined ON-CLICK actor the event is fired to that actor.

If the face B have no ON-CLICK actor the event is not catched anywhere.


We got a request to checnge this so there are few possible options 
we could use:


1. If face B doesn't have ON-CLICK actor defined then propagate the 
event up to its parent face (in our case face A) and up until any 
ON-CLICK is found. (If the face B have ON-CLICK defined then the 
actor is executed and propagation stops here.) In other words the 
event propagation stops in the closest found ON-CLICK actor during 
the 'bubbling' of the event upwards.


2. Propagate the event from face B thru its parent face (in our case 
face A) and up to the topmost(Window) face. The propagation/bubbling 
is done by default and can be stopped in any ON-CLICK actor on the 
way upwards by returning 'stop-event(or any other chosen) keyword. 
(this is simmilar to the model used in HTML)


3. (current behaviour) Don't propagate the event. Just execute the 
ON-CLICK actor in face B in case it is defined. Programmer have to 
manually add event propagation code to the actor if event bubbling 
is required.


4. Don't propagate the event by default. But introduce PROPAGATE/BUBBLE-ACTORS 
(or any other chosen word) option field that can be set for each 
face. The option could hold block of actor names that should propagate/bubble 
the events up.


Please, keep in mind that chosen behaviour affects not only actors 
that handle user input but also actors like ON-INIT, ON-MAKE and 
any other possible actors in general.


Please post either your favorite from the above options or even any 
other possible solution you think is better. Thanks for your help.

#4 is an extension to #3, and would be my first choice if #3 isn't 
enough. I generally don't like having to say "stop!" to avoid unexpected 
behavior. I don't know if #1 works well, though I think QNX Photon 
used it.


If the 'bubble option can be part of the style, then you can define 
buttons not to bubble on-click by default, but maybe 'text would, 
for example.

The approach outlined in #1 is similar to that employed by LiveCode 
(used to be called Revolution). It seems to be a good model. It additionally 
supports "user-defined" events in the same way.

To stop bubbling, you just define an empty on-click handler I assume?

Or does it have to return a specific value to say it handled the 
event?

#2 seems the worst of both "worlds"
#3 seems clear and workable
#4 appears to lead to complexity

Yes to stop bubbling you define an empty event handler.

I am thankful that you aren't considering the DOM 2t option - some 
events bubble, some don't.

* I do agree with Peter that #3 is clear and workable. Accepting 
any of the alternatives would require (a lot of, I am afraid) code 
to stop  unsolicited bubbling.

* #4 appears to lead to complexity, and thus it may be the worst 
alternative
* #1 looks like the second best to me
* #2 looks like the second worst

Yes, the alternative "some events bubble, some don't" looks like 
worse than any of #1 to #4

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'?