World: r3wp

Rebolek - I have always had the problem with the PANEL vs GROUP, 
because they used different native axis orientation, why NOT being 
the same style in design. I objected to Carl, that I always forget, 
which direction which particular style goes by default. But Carl 
told me, that it is OK the way it is ... I still don't agree, unless 
both styles have the same visual qualities ...

VPANEL, HPANEL - very non-rebolish names, but I already have seen 
a departure from pure REBOL naming convention, with LIB, SYS introduction 
- very non rebolish too, whatever BrianH says :-)

V-PANEL, H-PANEL might be more rebolish, but I first have to read 
about what we are trying to achieve here ...

btw- I never liked GROUP name. I want just one - PANEL - with vertical 
or horizontal orientation.

I agree with ChristianE - column, line, row, I even like horizontal, 
vertical (but only if it means organisation of widgets, without any 
visual additions)

Pekr: PANEL does not have "vertical or horizontal orientation". Try 
to understand before writing

Ladislav - I don't care, because you don't understand, what you mean 
...

what I mean, gee :-)

Simply put - any change from Carl's disagreement with me is vital 
for me.

I do care about the obviousness for the user first. I might not like 
VPANEL, HPANEL names, or ROWS, COLUMNS, but user at least imediatelly 
knows, what it implies.

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

 - that is important to know, and it will be missed by many, unless 
 properly documented ...

Originally, GROUP and PANEL were same styles with different orientation. 
That has changed and now GROUP and PANEL are two different layout 
engines. So we need to come up with names for horizontal and vertical 
variations of GROUP and PANEL. So far we've got H*/V*, but if there 
are better names, it can be changed.

Also the names GROUP and PANEL can be changed if someone can come 
up with a better word to describe the layout engine (like GRID for 
PANEL, but I think GRID should be reserved for true GRID style).

OK, why not to use parametrisation. The question is - do we want 
more names, or not? Or even - can the orientation of panel by changed 
programatically later? I know that during the runtime, corresponding 
"VID" code is not important, but if it can be e.g. changed, then 
it would be probably better to have them as parameters, e.g. PANEL 
#V [], but I understand why some ppl might not like it.

do we want more names, or not?

 - it's very simple actually. if the options are too comprehensive 
 or to unclear to set for a style, make a derivative style. so, work 
 it out from that.

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