World: r3wp

As status of RMA's GUI is more of a private effort targetting business 
level apps, I can imagine kind of simplification, which makes it 
"dumb, incappable and more rigid than possible", because it just 
fitst your limited business apps needs :-)

Yep, which are very limited and that's why people pay a lot for our 
stuff.

Ppl pay lots of money for crap like SAP, because there is no other 
way around for them :-)

Pekr: "I can imagine..." - that is where we need your imagination, 
since we strived very hard, but the goal to make it more rigid than 
possible seems to be elluding us.

Perhaps a summary of the proposed changes would clear the air?

The main problem at the moment is (and I hope I hit it correctly, 
otherwise Lad etc. will correct me) that it's not clear which ACTORs 
call which REACTORS. And if all REACTORS are executed or not. So, 
there is not logical relation between an ON-KEY event and an ON-KEY 
handler. Further, one sometimes need to first call the user-code 
event handler, than the style handler, or the other way, or in between.

So, we are thinking about making the handling of events much more 
clear.

In a simplified form:

- the DO-STYLE function will be renamed to DO-ACTOR

- both Henrik and Robert wanted to be able to influence the behaviour 
of actors from the Layout dialect,
- which was not possible yet,
- and was not compatible with the idea of reactors

- therefore, it looks like the best idea to introduce one new Layout 
dialect keyword (ATTACH),
- and allow to influence actors from the Layout dialect,
- making reactors unnecessary

- forgot about yet another Layout dialect keyword: OVERRULE

Wasn't there an ATTACH already? Or was it implicit?

There was ATTACH IIRC - it was used for scrollers mainly. In more 
abstract pov it might just call attached style's on-attach or on-set, 
I don't remember anymore. But - I also remember guys here said, that 
areas will not be done that way anyway (attaching just separate scroller 
style) ....

- making reactors unnecessary ...

 - understood, but doesn't it break Carl's idea of having most common 
 actions directly available in a layout, without any overhead? I mean 
 - reactions like DO, SUBMIT, BROWSE, CLOSE etc.?

Could syntax example be shown? E.g.

BUTTON "browse" BROWSE http://www.rebol.com

will become?

BUTTON "browse" ATTACH ????

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)