World: r3wp

A layout of faces

 could be an instance of any number of styles, yes. We just have to 
 accept that as a non-specific definition. That is, a panel is a face 
 that is a layout of faces, but it is not the *only* type of face 
 that is a layout of faces.

I think that RMA resolves the situation somehow. My final proposal 
is:

- panel/vpanel
- panel as container name plus style, stays as is

- remove word "panel" from content handling functions. I never like 
three word function names btw :-)

This is just my opinion, your point of view might vary ...

- panel as container name plus style, stays as is
 - I do not understand what this means.

Before, 'panel' was used as a style name. At present, it is not. 
It is still used in the documentation, but there it means something 
else (a "layout of faces"), which is inappropriate.

And, it is used in the INSERT-PANEL-CONTENT function name, where 
it is inappropriate as well.

That is why I am having trouble to understand what "stays as is" 
is supposed to mean.

Before panel was used as a style name

 - I exptect panel/vpanel to exist in upcoming releases ... and then 
 I suggest to remove word panel from the function name.

Sorry, forgot we have recently hpanel and vpanel ....

Some time ago Pekr suggested to rename the DO-STYLE function to DO-ACTOR. 
The proposal seems to have attracted the attention now, so, one of 
the last opportunities to express your preferences. To not be just 
abstract, In this example we call the ON-KEY actor for a certain 
given FACE, supplying it a certain ARG. Variants:

1) at present, the actor call looks as follows:

    do-style face arg

2) the variant proposed by Pekr is:

    do-actor face arg

3) is there any other variant you prefer more?

Correction:

1)

    do-style face 'on-key arg

2)

    do-actor face 'on-key arg

3)?

I definitely prefer 2.

I already expressed my preference, hence 2)

IIRC,I even suggested to also rename DO-FACE to DO-REACTOR ....

Another suggestion is to have them all end in *-FACE, so ACT-FACE, 
REACT-FACE. If you have another DO-* that works in a completely different 
domain, maybe that would be confusing.

We are going to re-factor the complete ACTOR & REACTOR stuff in R3-GUI. 
It will be streamlined, much simpler and more common in that it follows 
"best practices" from other GUI libs. The side effect is, that this 
is a bigger re-refactoring step and will take some time. Until done, 
we are not going to make a new release.

Streamlined typically sounds like simpler, less capable. I hope it 
stays as flexible as possible?

If you streamline well, in the REBOL way, things become more flexible 
and capable

view [ AREA [ red "12" green "AB" blue "ab"] ]
Caret cannot move to "12" and "AB". A bug, I think.

It will much simpler and more cabable.

Pekr: "I hope it stays as flexible as possible?" - sorry to spoil 
your expectations, but our main goal is to make it dumb, incapable 
and more rigid than possible.

:-)

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.