World: r3wp

et-panel-content
clear-panel-content
insert-panel-content
append-panel-content
change-panel-content
remove-panel-content

set-content
clear-content
insert-content
append-content
change-content
remove-content


; Disadvantage of following group is, that it does not relate to 
the content, and hence we are reserving/blocking those names for 
our particular purpose.
set-in
clear-in
insert-into
append-into
change-in
remove-from

Think about them in the usage scenario,e .g.:

insert-content my-panel [content here]
insert-into my-panel [content here]

1) Do you find the 'a layout' and 'layout style' notions to improve 
the current 'a panel' ambiguous terminogy, or do you prefer something 
else?


To me, a layout is a specification, not an instance. I don't know 
that using a different word (container or compound) helps. You just 
need to be explicit about whether you're talking about a panel face 
or the panel style (which has a layout specification).


2) Which of the three [[hpanel vpanel] [panel vpanel] [panel panel 
vertical]] alternatives do you prefer?


My view was based on there always being a base 'panel style, with 
'hpanel and 'vpanel being shortcut styles to set the layout mode.

Sorry I don't have time to dig into the other conversation right 
now.

You just need to be explicit about whether you're talking about a 
panel face or the panel style (which has a layout specification).

 - hmm, it never occurred to me how much the question could be misunderstood.

Do you think it is really the the sense I meant?

I never wanted to be able to discern the panel style and panel face

(which is quite trivial)

Yes. I must have misunderstood as I'm pressed for time, but wanted 
to read the docs this time, even if quickly. :-\

I thought you said that it was confusing in the docs what you might 
be talking about.

the word 'panel' was used as a name of the style as well, which means, 
that 

a panel" could mean "an instance of the panel style" instead. Using 
both senses makes the documentation (and code) rather confusing."

aha, the misunderstanding is what "an instance of the panel style" 
means

Do you mean a style based on the 'panel style?

no, "an instance of the panel style" means a face, the style of which 
is the panel style

That's what I thought. This *is* confusing. ;-)

I guess I'm not seeing how it is any more confusing in code, and 
in docs you can be explicit. But I'm obviously missing something.

Back in a bit.

So, for "a panel" we have the following two meanings:

- "a face that is a layout of faces" (this is what Carl used)
- "a face that is an instance of the panel style"


These two meanings are different, since "a layout of faces" may be 
a vgroup, e.g.

Notice, that both meanings mean a specific kind of face.

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