World: r3wp

yes, that is why I eventually thougt about renaming it :-)


rows 2 [button "1" button "2" button "3" button "4" button "5" button 
"6"]


columns 2 [button "1" button "2" button "3" button "4" button "5" 
button "6"]

... but - those are too general names, someone might think they belong 
to some grid style :-), so vpanel, hpanel, with above behaviour, 
would be OK for me ...

yes, columns/rows would be too general, thanks for your feedback 
;-) Anyway you can always do: stylize [rows: vpanel [] columns: hpanel 
[]] if you want.

hmm, looks easy to do :-)

Anyone thinks it should be some other way?
 I agree on the current behavior.

...the current behavior
 - am I right that you mean the one described by Pekr?

yes

OK, thanks

So, does everybody else want to "remain silent forever" in this respect?

Any other point of view, how Cyphre's code could be interpreted?

vpanel 2 [.....]
-> "I want 2 vertical panels" ->
button 1  button 4
button 2  button 5
button 3  button 6

Izkata: So how should system know, how many elements you want to 
have in each?

That's also how rebgui does it ...   across is default so vpanel 
2 [ .. ] is two coumns

columns

I've actually not used either, Pekr just asked for other interpretations 
- and that's how I first read Cyphre's code.


Pekr:  Elements divided by number, rounded up (with final column 
simply containing the remainder) is how I would do it...

The thing is: Either the number is like a SKIP refinement or like 
the number for LOOP

IMO SKIP is more useful as it eleminates explict NEWLINE items.

Izkata: understood, and how about the Hpanel? There you want the 
layout proposed by Pekr?

The number for rows/cols still isn't intuitive to me ("2 columns" 
or "2 rows" would be clear). As far as ordering, it would be nice 
if you could lay out your code so it "maps" visually to the layout.

That goes along with what Daniel (Iskata) is saying.

If you have V* than the number is always H and vice versa. IMO that's 
something good to remember. Otherwise source can become to chatty. 
And yes, laying out the code in the intended way is good style anyway.

Not his layout, but the idea of "I have n groups".

Aha, did not know, that RebGUI did it that way

So, if you specify an H or V mode (and mindset), then when you're 
grouping your faces, do you think in terms of a FORSKIP look or a 
SPLIT model? And what makes it easy to add a new row or col?

vpanel 1 [
	button "1"
	button "2"
	button "3"
	button "4"
	button "5"
	button "6"
]
vpanel 2 [
	button "1" button "2"
	button "3" button "4"
	button "5" button "6"
]
vpanel 3 [
	button "1" button "2" button "3"
	button "4" button "5" button "6"
]



hpanel 1 [

 button "1" button "2" button "3" button "4" button "5" button "6"
]
hpanel 2 [
	button "1" button "2" button "3" 
	button "4" button "5" button "6"
]
hpanel 3 [
	button "1" button "2" 
	button "3" button "4" 
	button "5" button "6"
]

an alternate type of grouping could be blocks of blocks:

panel [
	[button "1" button "2"]
	[button "3" button "4"]
	[button "5" button "6"]
]

not sure how useful that is.

Note, I am not saying that's what I expect, but rather it's to visualize 
how the orientation affects the order. 


Something else to think about is whether you can, or should be able 
to, invert H and V and have the layout still work.

invert H and V and have the layout still work

 - that is generally not impossible, of course, but it is against 
 the readability requirement Cyphre mentioned as his reason why he 
 proposed Hpanel and Vpanel styles instead of having panel #H panel 
 #V

In order to transpose the grid, you need to know the number of items 
in the opposite axis of the panel.

In order to be able to show the grid you need to know the number 
of items in both axes, but that is not the problem to compute

This is more a dialect design problem, i.e. what will be more "intuitive" 
for the user

I don' t know how the row/col value overrides, or avoids conflicting 
with, the width of the face, or if the parent' panel is sized as 
a layout, based on sub-faces and you can't change it. A pair! would 
have the same problem, if used to explicity state both the number 
of rows and columns.

Yes, and I think the grouping of the data in the code layout is the 
driving force there. The number tells you how many "groups" (H or 
V) and then you enter items so they are contextually related in the 
code.

A pair! has two more problems, actually:


1) it is redundant, since knowing the number of cells, and just one 
of the dimensions, you can easily compute the other one; such a data 
redundancy is, in databases, called "denormalized data" and is undesirable

2) the user frequently wants to give just one number, assuming, that 
the other is computed every time some cells are added or removed, 
thus, not wishing to give the value for both dimensions

1) Eliminating redundancy is not the same as normalization. 

2) "the user frequently wants to..." This is speculation, isn't it? 
:-) 


I could just as easily say that the normal case is that I know how 
I want my canonical grid laid out, and I may want to specify some 
cells to be empty.

the user frequently wants to...

 - that it is not a speculation, I was told by Cyphre that there are 
 at least two users frequently wanting that

And while we can say that normalization's goal is to eliminate redundancy 
in storage, we can also say that it doesn't solve the redundancy 
problem at all levels (e.g. when joining data). There are also reasons 
to denormalize. It's interesting to think about though.

specify some cells to be empty

 - the number of cells is given by specifying the graphical objects 
 in the layout; the software can count them and know the number of 
 cells; if you want to obtain "empty cells" just put in some Pads

...that there are at least two users frequently wanting that

I stand corrected. :-)

Pads - Yes, Gabriele's design had an elegant solution for this IIRC.

the last time I worked on a grid, the sizing values where autocomputed 
and shared accross rows and columns.

when one cell changed a single X or Y value, all the other cells 
of the same row or column where aware and could update on their own.

Please, keep in mind, that this discussion is not about computation! 
This is about the dialect, which must not be redundant to not allow 
to specify impossible combinations

the overall sizing algorithm took care of "collateral" effects.

but the *design* of the layout engine provides logical clues into 
how it should be expressed in terms of a dialect.

Max - Which brings up the point of what controls the size. Do the 
sub-faces control the size of the panel, or does the panel control 
the size of the sub-faces?

Ladislav - Yes.

if the system uses the whole column to resize things horizontally 
(width affecting word-wrap and thus controls height indirectly) then 
the height should be automatic.

should
 == "could"

to me a lot of this discussion resembles HTML table box model discussion... 
maybe you should look into how they solved the various issues.


for example, cells can "span", which is an elegent way to solve the 
gaps in cell data.

Yes, I think tables are key here (tbl did spanning long before HTML 
I believe :-). Do H and V panels help that much, e.g. to reduce clutter? 
I imagine the team talked about that, and whether just a TABLE would 
be enough.