AltME groups: search

I will be glad, if we have system, where I can easily style elements, 
and configure their parameters. I'll wait how you resolve the FRAME 
style or simply borderless PANEL, GROUP, etc.

the function is different, because it is different

 - it's different, because when you stylize, you make style objects. 
 when creating layouts, you are creating faces. faces and styles are 
 not the same kind of object.

guie/face: object [
	; Faces hold the state and options of instances of a style.
	style:   ; WORD!   - name of the style for this face
	facets:  ; OBJECT! - properties unique to this face
	state:   ; OBJECT! - state variables (not properties)
	gob:     ; GOB!    - graphical object(s) for this face
	options: ; OBJECT! - optional facet changes as specified
	tags:    ; MAP!    - tags for this face

	; NOTE: optionally extended in face creation with:
	;name    ; WORD!   - reference name
	;reactors; BLOCK!  - block of user actions

	; PANEL faces also add:

 ;trigger-faces; BLOCK!  - faces which reacts on triggers in panels
]

so we are going back to view layout [], or not necessarily, and layout 
is just a helper to prebuild a gui?

Hi, here is an R3-GUI poll once again:


For the resizing purposes, all elements have MIN-SIZE and MAX-SIZE 
specifying the limits of resizing. It is easy to see, that, unless 
MIN-SIZE <= MAX-SIZE in both coordinates, the requirements are contradictory. 
(For example, if we set MIN-SIZE: 100x100 and MAX-SIZE: 50x50 for 
the same object.) Currently, the code does not trigger an error in 
such case (not having a built-in test for it), giving the priority 
to the MIN-SIZE.

The poll question:


What do you prefer to happen in case object MIN-SIZE and MAX-SIZE 
dimensions are contradictory? Do you think the current behaviour 
is acceptable, or do you want the code to always trigger an error, 
if conflicting requirements are given?

I prefer that max-size have some meaning. So if the size is set outside 
of max-size, the size should be constrained to max-size. That is 
the whole point of having a max-size setting in the first place. 
If a style has a max-size setting below max-int/max-int it should 
be there for a reason, and max-size can be overriden explicitly in 
the layout so it doesn't constrain unnecessarily.

So, currently it seems to me, that Graham's idea to set the MIN-SIZE 
to be the minimum of MIN-SIZE and MAX-SIZE and vice versa, to set 
the MAX-SIZE to be the maximum of the MIN-SIZE and MAX-SIZE is supported 
by BrianH as well, and, possibly, Max would support such a method 
too, based on the fact, that it does not "jam" the application. Count 
my vote too.

As long as they are actually set that way, sure. If they are left 
as they are and then just interpreted that way at runtime, that can 
get confusing.

And the actual size should be constrained by min-size and max-size; 
setting the size outside that range should not push the limits outwards.

And the actual size should be constrained by min-size and max-size

 - the actual size is a result of the resizing algorithm, and it indeed 
 is clipped to the MIN-to-MAX range.

Yup. And it should continue to be clipped in that way :)

Using the true min and max value, regardless of which property they 
are in, may keep things from going disastrously wrong in some cases. 
If it were just the app programmer in charge of things, I would vote 
for raising an error. Resizing systems are another story, and I agree 
with the new plan in that context, though it would be nice if there 
is a way to trace the bad cases when they occur.

Are these size constraints set through accessor functions, or otherwise 
processed by standard code before they are applied? That would allow 
the min-size and max-size to be repaired before they are used, so 
the min constraints can be ensured to be <= the max constraints.

Are these size constraints set through accessor functions, or otherwise 
processed by standard code before they are applied? That would allow 
the min-size and max-size to be repaired before they are used
 - yes

in glayout I had a lot of these issues to manage, and generally, 
I always had some part of the setup func which would normalize all 
the values to layout function expected behaviour.


this allowed voluntary programmatic side-effects, but not thru the 
layout dialect.


for example, all sizing values where clipped to be at least as large 
as min-size as the first step.

I'm trying to change the font color and size in a button, and in 
a field ... need some help !

A small note:

I have ran the latest RE-GUI and the examples. I have see that when 
the CHECK is off the "v" is still visible but greyed.

In GUI language I have seen the GREYED "v" means BOTH "true" and 
"false".

Example: you want to filter in a database which customers are active, 
you set it to true,  which are inactive, you set it to false (nothing 
visible). You want both true and false the you have a third state: 
the grayed V.

I have problem accepting result of examples:

15, 23, 24, 25, 26, and I stop here, probably many others ...


The problem I see is,that I don''t want elements to jump during resizing 
the way it does. Please try form example 15. IMO if we don't support 
scaling, the text and its spacing should not change at all. I would 
expect panel being enlarged, but all it does is the panel moves down, 
and GUI creates space between the header text and the consecutive 
text.


Also - look at example 26 - why the last line of boxes is shifted 
down the window from all the rest of the boxes?

And you thought, I might like following coder, right? :-)

 view [hpanel [button button button] options [box-model: 'frame]]

If we can't come up with something better (which is beyond my imagination 
and the "proper" way would require to come up with xy alternate names 
for all panel/group combinations), I am definitely at least not sure 
about the facet (property) name. Does drawing the surounding frame 
(or simply parametrisation of one of style visual) has anything to 
do with the term "box model"?


I would probably use draw-mode name, but not sure it would not be 
confused with draw frames then? What do you think? Forget the syntax, 
we can't do any better here imo, but what about the name?

Align examples - I don't understand the align+halign at all. Why 
the vertical coordinates of red and blue boxes are reversed?

Also - please use halign instead of allignt, to be consistent with 
hpanel, vpanel, etc. It has imo no sense to name one property valign, 
and the other one align.

alignemnt - really - go to example #35, write down all variants on 
paper, forget the visual representation you are provided with, and 
just draw it on the paper out from your head. I bet you will make 
a mistake. And align + valign is not understandable for me at all 
....

Henrik - whatever name might work. As for EDGE - this is yet another 
term though. EDGE was regular facet in VID though, and in R3 it is 
replaced by BORDER, no?

I think the edge/frame/border usage is a little confusing. EDGE was 
a standard feature for every face in VID and it was fixed how it 
worked. In R3, an edge would be implemented on the DRAW level and 
could basically mean anything, including what it means in relation 
to the box model. This is why I'm still advocating a special FRAME 
style, which in *one* place, settles the meaning and the appearance.


Furthermore, a FRAME could be required for any type of face, be it 
a form with many fields, a compound of faces or groups of compounds 
of faces, which need to be surrounded by a pixel accurate frame, 
like in the example below, which I had trouble defining properly, 
when I experimented with skinning:

http://94.145.78.91/files/r3/gui/162.png


I had problems with it, because it had to be part of COMPOUND, and 
yet, certain COMPOUNDs would not have a frame and certain other panel 
types would also require the frame, but not be a compound. It is 
just much simpler to have it in a separate style.

but how would you define, what layout engine should be used? We have 
two, no? panel, and group ... and their respective vertical vs horizontal 
variants ...

The question is, if we can please all users. Some will like borderless, 
backgroundless clean style. Some might want frame around the panel, 
and I can imagine users wanting just a bit different color or gradient 
to distinguish the panel from the surrounding.

#[[Pekr

Does drawing the surounding frame (or simply parametrisation of one 
of style visual) has anything to do with the term "box model"?

Pekr]] - surely it does, the box model specifies that, and other 
properties

You don't need special enclosing face if you can use box-model for 
it and draw in the border.

Ladislav - box model/frame is not much of an issue for me. I think 
that worse problem for me is how currently resizing is behaving in 
above mentioned styles, and all that align examples and its naming 
- very confusing.

align and valign are pretty standard names if you've ever seen HTML, 
what's so confusing about them?

#[[Pekr
And align + valign is not understandable for me at all ....

Pekr]] - right you are, you should see the code to understand what 
the text means. In short, it means, that the HALIGN and VALIGN properties 
are set somehow, instead of using the default values, that are 'LEFT 
+ 'TOP

err, I meant: "ALIGN and VALIGN are set somehow, instead of using 
the default LEFT + TOP setting"

ok, my question towards the align, valign. I know we might want to 
be "compatible" to html, but to stay consistent - we have vpanel, 
and hpanel, not vpanel and panel. Wouldn't it be wise to use valign, 
halign too?

Regarding Henrik's FRAME note - that is a surprise for me, never 
heard about such a proposal, and disagree with it.

If you will say, that it is explainable by how the resizing model 
works, then I might reshape the question and ask how to avoid it?

#[[Pekr

E.g. try also panels-26.r3 - why the last line of boxes stays "attached" 
to the bottomof the window, causing a space?

Pekr]] - that is an example "inherited" from Carl, and it behaves 
as it should, taking into account, how it was defined. You need to 
take a look at the code

#[[GiuseppeC

I have ran the latest RE-GUI and the examples. I have see that when 
the CHECK is off the "v" is still visible but greyed.

GiuseppeC]] - you are not the only one who dislikes this. Count me 
in.

as you can see from the discussion between Henrik and Ladislav - 
 not even RMA has unified point of view on how some features could 
be designed. So what is problem with me not eventually agree with 
what you cook behind the doors? :-)

Two notes:

- RMA is neither me, nor Henrik

- RMA has a unified point of view, it is the one you can observe 
when examining the published code and docs, all other things are 
just speculations

And, especially from you, it is unfair, taking into account, how 
many times you did not put to use the oportunity to present your 
preference in various user polls. 'The informations about user preferences 
were much needed then, and it is a pity you, instead of helping us 
to know user preferences in many cases, try to dishonest our efforts 
publicly by misrepresenting it as "cooking behind the closed doors".

WTF is an attempt to insult your good will? Damned - this is SW development 
and desing, not a religion!

What users poll are you talking about? I do remember some, and when 
I can't take any preference, I don't participate. OTOH I put many 
comments in here. In fact - R3 situation is so "devastated" from 
the community point of view, that there is very little ppl participating 
in actually anything R3 related. Even in time of Carl's GUI, I might 
be the only public tester, may 1-3 other guys I remember. Where's 
all 300 ppl registered here with testing and comments? How much of 
input you get from any other person?

as for "cooking behind the doors" - where's the insult? Let's take 
an example with the FRAME. The only thing we knew for last two weeks 
was, that it will be somehow solved. And "somehow" = behind the closed 
door. I do remember Rebolek's preference of #FRAME keyword, some 
discussion about that, and then the release comes out, containing 
particular solution, which even Henrik (I regard him being part of 
RMA) questions ....

What I can see though, is a kind of syndrome of a developers, who 
live behind the closed door, and then wonder if another point of 
view is presented. It very often ends with statements like "you can 
take Carl's code, and do your own GUI". And I am far from alone receiving 
such a reply. And THIS is what I call as an insult, to ppl expressing 
different pov on the direction taken.

I very much respect Robert's explanation - this is not a democrary, 
this is RMA's business, and i have no problem with that. I just really 
don't understand, why when I put explanation to why I mistakenly 
marked panels-26.r3 demo as incorrectly behaving here, Rebolek comments 
that I am resisting something. I just put it here, because the group 
is searchable, and my reply contains explanation, which might be 
helpfull to others ...

This is really difficult to take, even for me. With each release, 
I download, go thru tests, read release notes, and I put my comments 
here on what i think about new additions, etc. I am the only one 
reporting actually anything here, so it logically can look like I 
am criticizing something. But could you please mark for me any insulting 
comment from my early morning report?

Guys, let's relax. Everyone can comment of course and people going 
through the code and comment help us. And it's OK if there are different 
POVs. As you can see even within the RMA team we discuss things back 
and forth and have different POVs. Which IMO is absolutly essential 
to come up with a good solution.

Some comments:

-the TEXT style in the release has incorrect resizing settings so 
it makes layouts that are being resized ugly. We'll fix that.


-regarding the introduced and discussed:  options [box-model: 'some-word] 

The defined word! symbol should specifiy box-model preset. By 'box-model 
preset' we mean group of facets attributes that affect the box-model 
settings of the specific face/style. So this option is IMO correctly 
named.

Currently the box-model option was added as temporary solution to 
the PANEL style only. But in the next release it will be possible 
to set it on any face in the layout or style definiton. Also we'll 
add basic set of such box-model presets that will be part of the 
system by default.


-ALIGN vs. HALIGN: yes, we borrowed the terms ALIGN/VALIGN from HTML(but 
note, it is used also in R2 font object and in R3 para object) . 
As people today are familliar with it and have it 'wired' in their 
heads using the same name could avoid silly bugs in their code.

I presonally don't think this must be consistent with names of styles 
but if majority people insist of such kind of consistency we would 
probably need to unify also the align word in the PARA object as 
well.

Petr, I appreciate the effort you're putting into supporting the 
RMA team, especially since I haven't made time to do so myself. We 
can probably blame text communication, and different communication 
styles for most misunderstandings.

Robert, please consider that people is nervous for the lack of development 
and communication from CARL....

Why not leave panel and hpanel as synonyms, and group/hgroup ?


It's entirely possible, but would that not make layout code harder 
to read/understand?

Cyphre:

box-model:
---------------


Few notes. Certain systems use FLAGs, which could be thought about 
as kind of switches, or representing certains states, etc., used 
in binary masks for e.g. Then we have TAGs. Even R3 GUI uses tagging 
- it is used mostly to mark particular face as behaving some way, 
belonging to some area, etc. And in that regard, I wonder if box-model 
type could be done just by using TAGs? 


What I think about TAGs in GUI in general is, that we don't use the 
concept to the max. I mean - if tags were not be flat block, but 
block of blocks, it could be used even more, e.g.:


tags: [box-model [tag1 tag2 tag3] style [internal] draw-mode [normal] 
resizing-mode [.....] ....]


Of course that might not work for us in all cases, because as you 
could see in above example, it would be difficult to distinguish, 
if something should be a facet, or a tag. E.g. if we would move DRAW-MODE 
into TAGS, then why not moving MATERIAL there too, etc. My question 
is - is there any rule for me to remember - what should be a facet, 
and what could be a TAG? (I expect the difference in how you work 
with them underneath)


My general problem is, that FACETS block is becoming long and messy, 
so what to do about it? There were following suggestions to think 
about:


1) close particular settings in subobjects/maps (whatever). There 
are settings belonging to the areas of resizing, colors, box-moderl, 
others, etc. The question is, if we want to refer to such values 
by face/color/bg-color for e.g.?


2) the simplest solution is to at least use some source code conventions. 
E.g. Carl introduced comments to particular ACTORS, desribing what 
arguments are supported for the function. So my idea is:

facets: [

   ; colors
   bg-color:
   other-color:

   ;resizing
    resizes: 
    init-hint:
...
]

ALIGNment:
----------------


It is probably not wise to change all subsequent areas to halign, 
valign. But anyway, we are a bit chaotic here, unless someone tells 
me, what's the rule here - to stay compatible to html/css, or to 
be consistent REBOL wise? I mean - if various areas use ALIGN/VALIGN, 
then my logical question is - why HPANEL/VPANEL, and not PANEL/VPANEL?


My comment is just food for thought, not a claim to change anything.

Dunno where to chat about Jocko's demo, but as Henrik suggested to 
move here:

- some parts are sluggish


- for Rebolek - you can look at Demo/To-Do section - Jocko outlined 
some changes he made to some styles. His demo does not work with 
current RMA release if I am not wrong.


- we should generally start to think, about how to "unload" certain 
GUI parts from memory. By just clicking here or there I got from 
11MB to 38MB of memory usage. In some old GUI I used, it kept track 
of windows, and those were GC'ed when closed. In REBOL, if I am not 
mistaken, after the layout, faces objects are defined, and there 
is no automatic way of how to "undefine" them and free the memory. 
So my question is - will that be addressed, or is user responsible 
for the resource tracking? And is it even adressable?

which is why in html we have align, and valign

What Graham suggests is also my question above ... and it would be 
consistent with subsequent align vs valign?

But - jokes aside, I am starting to like the idea of having PANEL/VPANEL, 
and GROUP/VGROUP .....

If I understand Graham correctly, he suggest to have default a horizontal 
alignment = compatible with underlying align/valign. Hence what he 
imo proposes (and I agree with), is to remove "H" letter from PANEL/GROUP

Graham:

Why not leave panel and hpanel as synonyms, and group/hgroup ?

Pekr:


I am starting to like the idea of having PANEL/VPANEL, and GROUP/VGROUP 
.....

so, you have to agree on the flow direction. :-)

Henrik, I think that Graham and Pekr really want the same thing. 
Panel and hpanel as synonyms, in other words - panel/vpanel. :)

One general question to GUI/gfx gurus. I know it is very preliminary, 
but - what about scaling? I mean - playing with my phone, I wonder, 
if it is facility of mobile OS, or particular app is receiving some 
zooming info, and acts accordingly? Are we ready for something like 
that? Because just recently, what we do is - resize. But we don't 
scale (fonts). It is just question of catching particular OS events, 
and create particular actors?

What I am seeins is, that e.g. in mobile Opera, zooming in/out, steel 
keeps content nicely resized/scaled. And even very small fonts are 
nicely readable ....

I saw scalling mentioned in some early VID documentation and probably 
some facets were reserved for it, but that's all that has been done 
I think.

I'm thinking about a style that is basically a fancy text list with 
the specific purpose of using it as a panel switcher. But specifically 
the animation part, it may be better to have some kind of actor (on-switch?) 
where the animation is handled and can be specified separately.

Old flyouts changed offset in loop, so if you switch panel's show-mode 
to 'fixed, you can make this effect very easily. You can also animate 
resizing this way, but GUI will be blocked because show is handled 
inside loop and not using timer event. But if you keep the loop short, 
user won't notice that the GUI is blocked.

We had a small discussion about MAX-SIZE this morning. In short, 
I don't like it and think it's not needed. Everyone else loves it, 
so it won't go away. Therefore I'm proposing a RESTRAIN facet (name 
not final). Without explaining what it is, can you guess what this 
does:

Before:

bar: box [
	facets: [
		init-size: 100x2
		min-size: 20x2
		max-size: 10000x2
	]
]

After:

bar: box [
	facets: [
		init-size: 20x2
		restrain: [vertical]
	]
]

restrain is not typical word of my english vocabulary (I know, my 
fault), and even reading its 20 meanings gives me almost zero idea 
of what it does.

facets: I'm all for keeping one single place to keep all these properties 
and throw everything in there. No further sub-structuring. Why? Because 
this would require a MECE approach (which is IMO a very subjective 
thing) and I have to remember more things. Now I know the stuff is 
in: facets/<some-meaningful-word>

Robert - OK, then lelt's keep the organized a bit by spacing (new 
lines) and comments, as I suggested ... that might be enough imo 
and grouping certain areas together helps users to faster identify 
particular related facet?

No problem with this. What I would like to have is a way that I can 
write:

? text-table/facets


And get a dump of all available facets and a description what it's 
for.

Hi, guys

Once again, congratulations for the excellent work done.

As Rebolek suggested in ALTME, I have some modifications to submit 
(of course, to check from your side) for the next r3-gui release.


I must first mention that I just realized this morning that the r3.exe 
 pre-compiled version of march 11th was not working properly, bugging 
with some very simple text displays (probably an old version). That's 
the reason why I did not update the demo with the most recent r3-gui 
file. By the way, the  build date displayed by the exe remains the 
same whatever the real building date. I don't know how we could have 
an automatic update of the build version.


Rebuilding from your sources (march 11th) allowed the demo to work 
properly apart from some appearence differences (I have even seen 
some bugs solved compared to my demo version). However, I will wait 
for your next weekly release ;-) to update my demo.

Coming back to the propositions of modifications :


It seems that there are definitions problems, or incompatibilities
in r3-gui (around line 66)        
;-- circle: [pair! | number! | number!]    
circle: [pair! | pair! |number! | number!]

in r3-gui (around line 1729) 
;-- scale: [decimal! decimal!]  
scale: [pair!]

also, I overload the drawing style by this code :
stylize [
    drawing: sensor [
        about: "Simple scalar vector draw block. Can be clicked."
        tags: [input tab]
        facets: [
            init-size: 100x100
        ]
        options: [
            drawing: [block!]
            init-size: [pair!]
        ]

        actors: [
            on-make: [
            ;    if block? drw: face/facets/drawing [
            ;       bind face/gob/draw: copy drw face/facets]

            ]
            ;-- JC
            on-draw: [face/facets/drawing]
        ]
    ]
]


Concerning the discussion of this morning on groups and panels, I 
would also prefer to have a default horizontal arrangement, and only 
precise when vertical: group, panel, vgroup, vpanel. A side effect 
is that it would remain compatible with Carl's doc.

By the way, it seems that tight is vtight. Logically, it should be 
htight.


That's all for the moment. When debugging the last demos, I may find 
other issues.

My notes to the HPANEL versus PANEL issue:

* Carl appears to prefer PANEL

* unfortunately, the situation is not as easy as it looks at the 
first look, since Carl's documentation uses the word 'panel' it yet 
another sense, every style able to contain faces, such as a group, 
etc. is called "a panel" in Carl's documentation, which would immediately 
lead to confusions, requring rewrite

* e.g. the INSERT-PANEL-CONTENT, or some other function names would 
be confusing because of the above mentioned issue, since the function 
in fact inserts content to any "face containing style", not just 
to HPANELs


So, the amount of rewriting both the code and the documentation would 
be quite big.

Ladislav, Carl told me that MAX-SIZE was necessary so that buttons 
would not become unnecessarily wide, but it is the wrong way to solve 
such a problem, much like putting a rock under the gas pedal to prevent 
the kid from going more than 30 mph in dad's car. Nevertheless, when 
(hopefully) we get some parts automated here, I will never need to 
deal with MAX-SIZE again directly.

And OSX does not provide maximum size for widgets, only windows.

Henrik - two things - first you should consult Carl (if he is available 
to RMA), and second - Ladislav will probably state, if there is a 
way of how to adapt his alghoritm, so that we can work without the 
MAX-SIZE? I personally don't mind MAX-SIZE anymore, as I have to 
set xy things anyway - hints, init-size, min-size, as needed. And 
if I am a style authoer, then I can always set MAX-SIZE to some artificial 
value, so :-)

much like putting a rock under the gas pedal to prevent the kid from 
going more than 30 mph in dad's car

 - that is a nice metaphor, but I would use a different one. In many 
 contemporary cars there are means to limit the revolutions of the 
 engine. They are there, and I do not think they are meaningless. 
 They limit the revolutions of the engine exactly like a rock under 
 a gas pedal eventually could (rock under a gas pedal certainly cannot 
 limit the speed).

As we have DO-TRIGGERS, what do you guys think about my CC ticket, 
suggesting to rename DO-FACE and DO-STYLE by DO-ACTION, DO-REACTION?

Jocko, rgearding the: circle: [pair! | number! | number!] definition.

This is correct as the definition doesn't describe the exact syntax 
of the command but it works more like the rules used by DELECT.

So in this case the CIRCLE command can be used only in these combination:
circle pair! number!
circle pair! number! number! 


which corresponds to the syntax described here: http://www.rebol.com/r3/docs/view/draw-curves.html#section-3


Ofcourse, now when the float pair! has been implemented we could 
extend the syntax for another pair to:
circle: [pair! | pair! | number! | number!]
to allow also:
circle pair! pair!


but this change needs to be reflected also in the to-draw function 
and dialect-draw definition object used by DELECT in the R3GUI.


I'll add this enhancement so it will be available in the next RMA 
release for you.


Also note, the current DRAW dialect (implemented by the preprocessor 
mezzanines) is trying to reflect only  the R3 draw reference documentation 
(in the link above) syntax which has been designed at the time the 
float pair! was not available. The review of the syntax is planned 
in the future.

Cyphre, thank you for the info and the link.

Please don't do special changes for me, unless you see a real interest 
to do so.

Just to explain what should the meaning of the UPDATE-FACE/CONTENT(S) 
be. It shall be used to "signal", that something inside the face 
has been changed, and the face needs update.

By the way, I probably should only be given 0.1 of a vote as I have 
hardly done any GUI programming with REBOL and certainly none with 
REBOL3.

As a non-native speaker CONTENTS sounds quite strange... and I wouldn't 
remember to add the S after a couple of weeks not using it.

Is CONTENT(S) the best word here? You said "to signal something inside 
the face changed, and the face needs to update". How about:
- DIRTY
- MEMBERS
- STATE

'Content sounds singular; 'contents  sounds plural. Are there more 
cases than resizing and members changing to consider? It's a very 
general name, and 'content or 'contents doesn't add a lot of meaning 
to what it does exactly.

Because of the difference between UPDATE-FACE (meaning: face dimensions 
changed) and UPDATE-FACE/CONTENTS (meaning: face contents changed), 
neither of /DIRTY, /STATE makes sense to me. /MEMBERS instead of 
/CONTENTS looks more appropriate than the other alternatives, but 
still not preferable to /CONTENTS (at least to me).

Both words are in my english->danish dictionary. The danish word 
is "indhold", and it can be both singular and plural.

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.

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.

/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

aha, after correcting and adding Gregg:

/CONTENT:/CONTENS = 4:6

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

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.

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?

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