World: r3wp

Hm, really. I'll have a look at that.

Henrik - the style browser text-list is somehow flawed :-)

 The correct phrase would be: "Henrik - The style browser shows a 
 problem in the text-list style, which is a good thing, because it 
 means Rebolek can fix it. :-)"

lol

No, the correct way is as how I put it :-)

flawed = it has erorrs. Somehow = dunno, what could be the cause. 
Ignoring the smileys is ignorance at max :-)

max <> maxim :-)

I know what you mean, but the style browser is meant to display any 
flaws. It's a great testing tool.

Henrik - I said nothing. Maybe it is incorrect wording, dunno. What 
is more I even said "text-list is somehow flawed", not that style 
browser is flawed. It took me 3 min. to find a problem, so keep it 
coming ....

One more question...what result would you expect in the following 
examples:
Example 1:


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

Example 2:


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

???

example 1 - vpanel:

button 1   button 3   button 5
button 2   button 4   button 6

example 2 - hpanel:

button 1   button 2
button 3   button 4
button 5   button 6

Of course, I expect "typical" - from top-left to right-bottom direction. 
Not sure, how gui would look like, if I would try to think about 
arabic support for e.g.

ok, so the number would means 'columns' for hpanel and 'rows' for 
vpanel. Anyone thinks it should be some other way?

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