World: r3wp

Aha, sorry, I guess, that I did not read the latest questions from 
Bolek/Cyphre

The Panel style until now lays the gobs horizontally; in a Panel 
with at least two columns, the second gob is laid out to the right 
of the first one.

If a VPanel existed, then it should lay the gobs out so, that in 
a VPanel with at least two rows, the second gob should be laid out 
below the first one. Does somebody see this differently?

The problem is we are trying to eliminate the need for using column 
definitions in case of one row/one column layout.

Currently you would write:
view [
	panel 1 [
		panel [
			button
			button
		]
		panel 1 [
			button
			button
		]
	]
]

or in case of 'inverted defaults' for panel without any number:

view [
	panel [
		panel 2 [
			button
			button
		]
		panel [
			button
			button
		]
	]
]




Which would make two panels in one column. First panel would have 
2 buttons in one row and second panel 2 buttons in one column.


I personally think this description of the same layout would be more 
readable:

view [
	vpanel [
		hpanel [
			button
			button
		]
		vpanel [
			button
			button
		]
	]
]


So the key is to improve readablility of the layout definition in 
cases that will be used from 99% IMO.

Anyone have better solution?

regarding the words chosen: I thought it would be better to have 
it short without any '-' or parameters as this would be annoying 
due the frequent usage.

As for naming - it was/is Carl, who tends to be picky upon the names. 
It is very understandable, otoh we introduced many concepts, as face, 
feel, which will say nothing to ppl coming from external environment. 
OTOH when I talked to Carl during the period when he tried to redefine 
View, he said something like - ppl will extend/improve/use system, 
which they like to use. So - with vpanel, hpanel, it is imediatelly 
imo obvious to users, what does it mean. I know that we can learn 
from docs first, but there is nothing better than self-explanatory 
code. We have to find some balance here, and with more higher level 
dialects, I would try to be closer to occassional users, rather than 
sticking to strict REBOL naming conventions ... that is my opinion 
...

I like vpanel/hpanel more than panel 1/panel 2

I might not understand it properly, but - new VID can't use variable 
number of arguments. Hence HPANEL/VPANEL above don't specify number 
of columns/rows? What if I want:


HPANEL 2 [button button button] ;--- third button under the first 
one? Possible?

VID can't use variable number of arguments - It can.

don't want to distract the discussion - but since when? It was based 
on DELECT, which did not allow anything like that, no?

DELECT allows a variable number of arguments. But the order of arguments 
must be fixed.

<paradox>the proposed VPANEL is actually equivalent to HPANEL 1 (== 
HPANEL with one column), while the proposed HPANEL might be equivalent 
to VPANEL 1 (VPANEL with one row), as I see it</paradox>

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?