World: r3wp

well, I would call it expected behavior. you have a known model you 
can simulate in your head.

Ladislav - would renaming it to simply COLUMNS/ROWS help the case? 
COLUMNS 1 is equivalent to ROWS, but it is still obvious .... well, 
imo :-)

Well, Pekr, if writtent this way, I wonder whether COLUMNS 1 could 
be understood as "a layout having 1 column", instead of "a layout 
having 1 row"?

(vice versa with ROWS, of course)

we still talk mostly about naming in regards to orientation. But 
what about GROUP or TIGHT (if TIGHT style still exists), which use 
different layout mechanism? If we would user COLUMNS/ROWS, it would 
not work as far as naming is concerned ....

Back to ACROSS and BELOW, then? Those have never been misleading, 
they just weren't styles in R2/VID but layout directives which were 
lost after the layout phase finished. And make the difference between 
PANEL, GROUP, TIGHT behaviour an attribute to them, with reasonable 
defaults. Would that even work?

layout [
	below [
		across [ ... ]
		below [ ... ]
		below 'tight [		; TIGHT behaviour
			button
			button
		]
	]
	across [
		...
	]
]

re across, below: I'm afraid we have to be style specific here. Using 
the across, below we would end up with two big styles that are trying 
to do everything.

what about GROUP or TIGHT...

 - in case of GROUP it would become VGROUP and HGROUP. The TIGHT style 
 I see more loke a shortcut that can be specific to single kind of 
 container. Even if we have only PANEL and GROUP it would be specific 
 to only one variant. IMO the TIGHT style shouldn't be probably in 
 the basic style set. It would be better that user 'stylyze' the basic 
 styles  which with different box-model parameters according to  his 
 own needs.

re TIGHT - agree - I never understoon, what is it in fact good for. 
Each person can have his/her own idea, of how much spacing he/she 
needs ...

TIGHT is just a shorcut. I was using it, but I won't miss it if we 
agree to remove it.

TIGHT, I believe, is a concept that is useful, when you don't consider 
compound styles, which only works, with Carl's dead simple styles. 
Now that we have compound styles, it makes better sense to have a 
specific COMPOUND panel that produces the desired spacing.

What does it mean to have a compound style?

area+scroller for example

I forgot how it is implemented. Now scroller is defined in terms 
of area, but is the source code of scroller shared/reused?

yes. you can also do view [scroller] ;)

yes, not much usefull, but happy anyway :-)

I'm doing a document on compound styles. They are easy to understand. 
I ran into a few snags, which hopefully will be solved this week, 
and then you'll get the document.

Bolek +1 - Don't use GRID for these names, unless we call it a canonical-grid. 


Christian, I thought of across/below as well, but understand Cyphre's 
reasoning.

Panel 1

 or "group 2" give little meaning to the numbers. H and V prefixes 
 make things clear, but...


groups flow faces by their individual size, like Google Images, while 
panels use a grid of cells.
 


What are the use cases for each style? Is it accurate to say that 
PANEL is for cases where you want things neatly aligned, and GROUP 
is for cases where alignment isn't important, and tighter positioning 
based on face size is desired?

yes, it could be something like that.

But for Google like positioning would be good to have own style as 
it's used for block of images with variable width where you don't 
specify number of items per row.

New R3 GUI with dynamic panel content functions:

http://94.145.78.91/files/r3/gui/r3-gui.r3

Style browser:

http://94.145.78.91/files/r3/gui/style-browser.r3

wow :-) What's dynamic panel content?

replacing faces with different faces in a panel.

SB crashes on slider ....

yes, a problem with DRAW.

Henrik - the style browser text-list is somehow flawed :-) I can't 
e.g. see area there - when you drag a scroller a bit, you can see, 
that the list changes, listing styles, which were not available in 
previous view :-)

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?