World: r3wp

possible, but adds more validators.

If I want to allow both empty and only-chars, then I have to explicitly 
express that. But only-chars itself has to fail on an empty field, 
no? Maybe I am just wrongly guessing something from the validation 
test example form field descritions ... I will wait for docs ...

Pekr, I understand what you say, but I would call it "going the long 
way around".

I think I still don't understand the issue. And also - many users 
might not care much about the implementation issues, but about the 
validity of the output. And not-numers positive validation for an 
empty field is simply incorrect imo ... I will wait for the planned 
changes, and then reevaluate ...

The output is entirely valid from the system's point of view, but 
the question is if users will understand it.

Machine should have never a precedence instead of the human common 
sense :-)

The trick is to make the two concepts mesh. That is why I asked the 
question above in the first place.

What about introducing special validators then? I know that would 
create several possible combinations - not-empty-only-chars, but 
you could still be safe. Just thinking loud. And also - the naming 
conventions: 

not-empty --> required
not-empty only-chars --> required-chars
not-empty only-numbers --> required-numbers


Also thinking about the analogy to parse, but ppl would have to be 
familiar with parse dialect:

some-chars (includes not-empty)
any-chars (empty or any char)

not-empty --> required -> already in use, but others could be considered.

new validation prototype at:

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

requires a new R3 GUI:

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

the ON-VALIDATE actor allows you to modify the face, based on the 
validation result. also simplified the validation process a bit, 
while adding the ability to use ANY for validators, as shown in the 
"Eric or James" field.

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.