World: r3wp

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?

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