World: r3wp

INSERT-LAYOUT-CONTENTS actually is OOP style, since:

- you don't specify the style, the style of the face is used

- the "/" is not used in all OO languages, and is not the only way

- as noted above, the current INSERT-PANEL-CONTENT name is inadequate, 
since it does not respect, that the layout may not be a panel at 
all

aha, I thought that insert-panel-content is only good for inserting 
stuff into panel style pane, but now I remember, that when we met, 
you already explained to me, that the style is more general?

Right, the function is a method to insert contents to any layout: 
vgroup, backdrop, my-pink-panel, ....

Then I can imagine:

INSERT-LAYOUT-CONTENT
INSERT-CONTENT
INSERT-INTO
INSERT-PANE

insert-into my-panel [content here] looks short and reads nicely 
....

no need to explicitly explain in the function name then imo, as it 
is defined by the followed argument?

OK, we shall consider this alternative as well, when doing the renaming.

It makes also the function shorter. What are other content function 
names though? We would have to come up with some short names even 
for other such funcs ...

OK, I can see them ... will provide some alternatives shortly ...

list of the *CONTENT functions (current names):

SET-PANEL-CONTENT
CLEAR-PANEL-CONTENT
INSERT-PANEL-CONTENT
APPEND-PANEL-CONTENT
CHANGE-PANEL-CONTENT
REMOVE-PANEL-CONTENT

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.