World: r3wp

Parser issue. Will see if it can be fixed.

updated validation.r3. added also a field for the only-chars validator.

I'm thinking there is a design issue with validation, particularly 
the initial state:


The latest version will show that the "Only Chars" field validates 
as OK, which is technically correct, but confusing, as absolutely 
nothing has been entered in the field.


The issue is that the VALIDATE-PANEL/INIT function will see the field 
prefilled with an empty value and this passes validation. All fields 
that show a black dot, actually fail validation and a black dot is 
shown as the initial state.


I understand what this means, but it may be confusing for someone 
who is using the validation system for the first time. The fix is 
simply to add the NOT-EMPTY validator to the field, for the field 
to fail validation initially.

Is this easy to understand?


I've studied the issue with setting an initial state for each field, 
but then there would be a problem with the validation system understanding 
prefilled values, and I would have to add functions to the validation 
system to mimick SET-PANEL that setup fields in a special way. I 
don't want to bloat the GUI like that. This method works fine, as 
long as you know what's going on.

Are you replying to yourself?

As for me - this sounds so complicated, that normal person can't 
know what you are talking about at all.

I'm asking the question, but it seems to be difficult to understand 
the issue.

Pekr, if you try the validation.r3 file again, you will see one field 
showing up as OK.

I just don't understand, why is that being a design issue? Any design, 
which pretends empty field belongs to "only chars", is wrong. And 
if it is difficult to fix, then the validation mechanism design is 
wrong as well ...

how is that implemented? Are you using parsers? What is the problem 
to check for the empty string?

The issue is that the VALIDATE-PANEL/INIT function will see the field 
prefilled with an empty value and this passes validation
 - why is that so?

What is the link to validation docs/proposal?

Is validation a fundamental gui aspect that has to be dealt with 
now?

Not numbers
 field fails too with an empty field ...

Graham - that is my ethernal question with the GUI project :-)

As for me, I can imagine Henrik doing much more important work, especially, 
as we have just few basic styles, which are even not working properly 
yet. But - we can't see the big picture. Henrik's work can go in 
parallel, and I think that Robert is sane enough to know what he 
is doing/requesting and why. That means - we have to be missing something 
...

Graham, yes.

I hope soon enough we will be able to see fully working area, navigation 
by keyboard, tabbing system (including the ability to set the order, 
skip certain widgets, etc.), styles like tabs, tree (fully keyboard 
navigation support), table/grid (ditto). With those three styles, 
we can be kings ....

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