World: r3wp

not too much, but we already have demos, styles based on styles, 
etc...

I did mean it to some degree, that it's a good idea to get a clear 
view first, when doing such things. Then you don't have to change 
anything later. But it's hard.

So make a cup of green tea, sit in lotus position, close your eyes 
and think. After a while, you might see it clearly and don't have 
to poll. ;-)

view layout [zen]

As far as I am concerned, I "see it clearly", but I do know, that 
if I wrote it that way, you would come and say: "my dog prefers the 
other alternative".

That is why I am asking beforehand, when I feel the time is right 
to ask.

Ladislav - in your GUI terminology doc, panel/vpanel section, isn't 
there a typo in the source code? Imo it should be panel [button button], 
not hpanel [button button]

Interesting - I really don't know, if it is a problem or even confusing, 
when docs talk panels in general, and panel as a style. How often 
do you need to refer to the panel style in your text? And if so, 
you can always use "panel style".

Imo it should be panel [button button]

 - that is just copy&paste, as you correctly noticed, describing the 
 current state

panel style

 - the problem is not much about "panel style". It is more about the 
 need to refer to faces, that are layouts (like windows, backdrops, 
 vpanels, I don't remember what, ...) , or faces, that are panels 
 in the sense of having the panel style.

While the "container" word is used in some GUIs, I like "layout" 
word, as we are used to it. The question is, if we want to preserve 
"layout" word for something else, or not. But generally "layout" 
translates to my brain like a "design", "description", whereas "panel" 
is concrete - just a panel.

I don't understand your last sentence. Could youcome up with short 
documentation sentence, which might show what the trouble is?

also - layout-mode alternatives could be - direction, orientation. 
But those are not much shorter. Maybe just a "mode", but there might 
be xy modes, so not enough self-explanatory

just a brainstorming on my part, no suggestions yet ...

For example,(this is not much a documentation issue, it is a coding 
issue, in fact): There is an INSERT-PANEL-CONTENT function. The function 
is supposed to insert contents to any layout face, i.e. the name 
is inadequate, in fact, and it should preferably be renamed to INSERT-LAYOUT-CONTENT 
(or INSERT-LAYOUT-CONTENTS, respecting the results of some of the 
previous polls).

Does that suffice to illustrate the problem?

yes, thanks ...

but - imo insert-layout-content is not logical. Imagine OOP way of 
things. You have a panel style = class (let's pretend it is a class). 
Then in normal OOP environment, you would see "insert", as it's method, 
no? Hence panel/insert, panel/delete, etc. So you should not imo 
name your function using a "layout" word, while keeping the style 
named "panel"?

I am probably OK to stay with the panel name of the style, panel 
name in supporting functions, and still referring to it as a panel. 
I simply regard panel style being one of possible implementations 
of the panel layout concept  :-)

We should also admit, especially as proposed by Henrik and Gab in 
the past, that maybe, many users will create descendants, calling 
them my-panel, my-red-border-panel, whatever. Then I can imagine 
some docs:


My pink-big-panel panel, is a special purpose panel, designed for 
my girlfriend :-) It differs from default PANEL STYLE in having red 
and pinky design ....

I think that ppl will find their way around it ...

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