World: r3wp

I just think that the work is running in multiple levels (native 
- Cyphre, styles - Rebolek, high-level - Henrik), and at some point 
in time, it will all settle down and merge together ...

Pekr, I see you don't understand the design of the only-chars validator: 
Each validator is single-purpose. This one checks only if only chars 
exist in the field. You can combine it with another validator to 
get stricter validation.

There is no problem with checking for an empty string, but the only-chars 
validator does not check for empty strings. The not-empty validator 
does that.

Of course I am tempted to see things we expect most - more complete 
styleset and at least basically usable gui, but I will test what 
comes-out, as I think talking about what will come next just makes 
guys nervous :-) Of course some basic time-frame  would be usefull 
...

but only-chars CAN'T be imo true for an empty string, no? :-)

Time frame is ASAP. The work is being done for apps (now not one, 
but two) that need to get into the field by RM Asset as soon as possible.

Pekr, what if you have a case, where you want both?

Henrik - can you please repost link to your validation related doc?

The doc is not yet updated for the latest validation prototype.

Perhaps the discussion should wait until that is completed.

Henrik - that would be OK, no? It is imo about perception of what 
are you expecting. If I ask - non-empty, that means something is 
entered, whatever. If I ask only-chars, it should validate only if 
chars are entered = include non-empty state by default ...

Simply:

not-empty - some value of any type has to be entered
only-chars - only chars allowed (len > 1)
only-numbers - only numerical values allowed (len > 1)

yes. what if you want to allow both empty and only-chars?

some-chars, any-chars?

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.