World: r3wp

http://en.wikipedia.org/wiki/Content
Funny it's called a "content provider", not "contents provider".

My understanding is that content refers to what is inside, contents 
refers to a list of the content

After looking in dictionary on my computer, I'll say contents (plural) 
is more correct english.

The plural form:

the things that are held or included in something : he unscrewed 
the top of the flask and drank the contents | he picked up the correspondence 
and scanned the contents.
The singular:

the amount of a particular constituent occurring in a substance : 
milk with a low-fat content.

So I would be content with content

:-)

Ok, from now on, all new words in REBOL will be in esperanto. English 
is too difficult!

I think both forms would be correct, with contents a little more 
specific, and content a little more abstract, and shorter

when you have to move on short notice and you sell everything in 
your house, it's called a "contents sale"

Further explaining my explanation above, one would use contents when 
the items contained therein are easily numerated .. and content when 
it is not.  So, content provider because the items can not be easily 
enumerated, and vary from time to time.  So, on this basis one would 
use /contents because one can always enumerate the members of the 
object.

but if the object only had a single item, we would have to switch 
to use /content

So in contents sale, it would mean all the content

in a contents sale, one can list each item ...

a suggestion for the next release of r3-gui : the doc style (the 
doc parser) interprets the first line of text as a title, which is 
not always appropriated. For instance, in a simple 

alert "this is an alert", the text is displayed as title. I think 
that this feature should be removed.

jocko, the DOC style is using the MDP markup now so my guess is we 
would rather use different style for alert layouts. We'll look into 
it.

on CONTENT/CONTENTS:  As a native speaker, the singular word can 
be thought of as referring to a single collection.

so either makes sense, IMO

/CONTENT:/CONTENTS currently 5:4 (counting Cyphre for /CONTENT and 
me for /CONTENTS)

...and counting Robert for /CONTENT (the other alternatives are not 
more explanatory)

...and Graham seems to prefer /CONTENT if I understood it well

It's a draw, so make both available. Mayby not in this situation, 
even if more than one option can be good in many cases.

No, I've changed to /contents :)

I don't think I really voted, but I would go with 'contents as well. 
'Content seems to close to the meaning of set-face in my current 
mindset.

aha, after correcting and adding Gregg:

/CONTENT:/CONTENS = 4:6

(sorry for the typo)

It's a draw, so make both available
 - although possible in this case, it prevents unification

is it possible to find a different word?

Would it work to make update-face/contents the default, so removing 
that refinement, and add a /resize refinement for that case?

Assuming I understand the current use correctly for resizing.

aha, counterproposal:


- make the current UPDATE-FACE/CONTENTS behaviour the default, and 
for the other variant use something like UPDATE-FACE/SIZE (looks 
better than /RESIZE) to me. The trouble is, that the exception is 
the UPDATE-FACE/CONTENTS variant, since it can be used only for hpanels, 
vpanels, hgroups, vgroups, etc., while the default behaviour can 
be used for all faces.

Actually, the behaviour of UPDATE-FACE/CONTENTS called e.g. for a 
vpanel is equivalent to the behaviour of UPDATE-FACE called for a 
face contained in the same vpanel.

Is the behaviour recursive, in the sense the if a vpanel includes 
some hpanels the faces inside the hpanels are also updated?

The behaviour is recursive in that if I call UPDATE-FACE, then all 
parent panels up to the main window are updated.

(i.e. the other way than you guessed)

So if I have a vpanel which contains two hpanels and call UPDATE-FACE/CONTENT(S) 
will the contents of the hpanels be re-sized?

I was going to suggest a couple of alternatives but it is hard to 
find something that fits in with the VIEW/VID/GUI metaphors.

Two notes:

- update is not resize, but can provoke a resize as well

- if I call UPDATE-FACE/CONTENTS on a hpanel, then the hpanel is 
updated (row and column sizes are recalculated, the total panel size 
is recalculated), but the panels contained are not

As opposed to that, when I call UPDATE-FACE on the same hpanel, the 
row and column sizes are not recalculated, since there is no reason 
for that

Thanks for the explanation. You could consider:

 UPDATE-FACE/RECURSIVE (or R) which is common with cl utilities but 
 most un-REBOL like
	UPDATE-FACE/ALL - based on LOAD and SAVE metaphor
	UPDATE-FACE/CHILDREN

I'm not sure if the parent/child metaphor is appropriate in REBOL3 
GUI.

UPDATE-FACE/RECURSIVE
- this is a misunderstanding, as I said.


- UPDATE-FACE if always recursive, i.e. the it updates all the parents 
as well.
- UPDATE-FACE does not "recurse to children"

UPDATE-FACE/CHILDREN
 - a misunderstanding again, see above

UPDATE-FACE/ALL
 - a misunderstanding as well

I'm afraid that I'm a little lost - You said that UPDATE-FACE/CONTENTS 
called e.g. for a vpanel is equivalent to the behaviour of UPDATE-FACE 
for a face contained in the same vpanel.


To me the faces contained in vpanel can be considered children of 
the vpanel.

Yes, but that does not mean any children recursion, that is a parent 
recursion.

UPDATE-FACE recurses to parents.

Parent recursion means, that when I start with you, I continue with 
your parents, grandparents, etc. As opposed to that, when I do a 
child recursion, when I start with you, I continue with your children, 
grandchildren,...

That I understand. But I don't understand why you think UPDATE-FACE/CHILDREN 
would imply child recursion. For me, UPDATE-FACE/DESCENDANTS would 
imply child recursion.

aha, I was misled by the word. Now the question is, whether it will 
not confuse other people as well.

I'm confused. :-)


I agree that /SIZE is a better name, and now see the problem with 
it.


What does the docstring say for the function? That is, can we approach 
it from the documentation side and see if the functionality is clear.

I intendedly did not want to be too much function-specific, since 
the "CONTENTS issue" is present in other function/refinement names 
as well.