World: r3wp

Not sure it would be usefull today, but would it be possible to have 
some validation per keypress? In the past I remember fields, which 
were defined as variable to get VTG = $("A", "B"), allowing to enter 
only A and B (for the floppy drive purpose :-)

Will give it a try in the evening ...

yes, I'm considering how that will work. it needs to be simple.

need to get into the field by RM Asset as soon as possible

 ... wouldn't they be better off using R2? I gather SDK is not a requirement?

It was decided a long time ago to do future projects in R3 as we 
felt that continuing to write testing tools, frameworks, etc. under 
R2 would give a big pile of work later, when converting that to R3.

Considering also that the result of that decision is that Carl is 
now in tight communication with RM Asset, I think it was a good decision, 
as we avoid the months of darkness without info. It gives RM Asset 
control in what direction to take the GUI and to work towards R3 
being a usable product as quickly as possible, when you have to answer 
to other companies and customers. SDK is also a requirement, that 
we hope can be pushed through as quickly as possible.

Ashley - forget R2 :-)

Pekr, I'd like to hear your opinion on this: Instead of PANEL and 
GROUP there will be VPANEL, HPANEL, VGROUP and HGROUP. Is it end 
of the world as we know it, or are you fine with it? ;)

There are some more details: The reason would be to no longer have 
it be unclear from source what the layout direction is. Prepending 
V and H removes that doubt. Also you would no longer need to write:

panel 0 [...

to get a horizontal panel with an infinite amount of columns.

just write:

hpanel [...

that's how glayout has been doing it for years... :-)

Is anyone using glayout though?

well yes... some clients.  :-)

I thought it was a great pity you never finished it

it always was a prototype.... and the finished product always was 
meant to be glass.

right now, glass is being used in my largest commercial app I've 
ever developped and its 100% stable.

100% stable just means not enough beta testers!s

Henrik, I too think the biggest difference between a VPANEL and a 
HGROUP is the orientation, more so than applied or missing spacing/padding 
as is established thru PANELs vs GROUPs. Yet with this naming is 
encoded in just one letter H and V.  

What's the reasoning to not use something like PILE [...] vs LINE 
[...] or just COLUMN [...] vs ROW [...] or, even, HORIZONTAL [...] 
vs VERTICAL [...]?

ChristianE, good suggestions, I'll pass them on.

And making the difference between GROUPs and PANELs an attribute 
to those? Are there fundamental behavioural differences between panels 
and groups?

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

Yes, unlike in Carl's R3GUI, PANEL and GROUP are now different internally.

Ok, I see. In Carl's R3GUI it was mainly spacing/padding, IIRC.

the thing is the we now need 4 names instead of just two.

Just thinking loud: What if, since as you say, panels use a grid 
layout, you just name them GRID? With ROWs and COLUMNS being horizontal 
and vertical subtypes of GRIDs. Like PILE and LINE could be subtypes 
of GROUPS. GOUPS and GRIDS finally being subtypes of PANEL. I don't 
think the behavioural difference between "your" groups and panels 
is communicated very well by these names inherited from Carl's work.

Rebolek, yes,hence my question on making PANEL and GROUP behaviour 
an attribute ;-)

I do understand that you want to express the behavioural symmetry 
in PANELS and GROUPS. It's a bit like multiple inheritance: Inherit 
behaviour from PANEL or GROUP, inherit orientation from HORIZONTAL 
or VERTICAL. That's 4 possibilities, and any name chosen is likely 
to overemphasize one aspect over the other.

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.