World: r3wp

Style browser as it looks right now:

http://94.145.78.91/files/r3/gui/241.png


Second validation prototype test window. The use of multiple draw 
blocks still doesn't work, so I'm resorting to funky yellow text 
fields to indicate validation state:

http://94.145.78.91/files/r3/gui/242.png

Good to have at least something visual! As for use of multiple draw 
blocks - is it feature which is going to be implemented? I remember 
when Carl did VID 3.4, it was not plan. But I could not understand, 
how else some more complex styles, could be built, displaying various 
states, which are not easily doable by only parametrisation of one 
draw block. If it is planned, it is a good news.

Yes.it will be definitely supported.

Pekr, already fixed.

http://94.145.78.91/files/r3/gui/243.png- Shows proper indicators

http://94.145.78.91/files/r3/gui/244.png- Shows validation report

Thanks. Btw - were we succesfull in getting in contact with the gfx 
artist? IIRC someone suggested one person to Robert, but I think 
that the person in question was not interested. I wonder if Amiga 
community could help here? :-) I think they will be kind of friendly 
to REBOL, because of Carl. Or put it another way - will you Henrik 
come up with some final skin, once there is a time to address it?

No action done yet. We need more things working otherwise the risk 
it to high to throw things away.

I will, but this will be saved for the end, when the GUI is stable. 
I don't want to discard anymore skin work.

I was thinking more about some mock-ups, rather than someone altering 
new styles to some new design. But as you said - it might be preliminary 
and there are more important things to solve first. If the  system 
is good, I bet there will be more stylesets/skins anyway. rebol.com 
needs some designer too :-)

New R3 GUI at:

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

New validation prototype, which can run stand-alone, at:

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

any new stuff regarding core of the engine, or styles, which could 
be tested?

Validation notes:


1. can't tab out of a field and unfocus does not activate the reactor

2. numeric fields will respond to an empty field or a number. they 
are string fields for now.

Pekr, just worked toward getting the validation examples working. 
Fixed some bugs in this regard. If anything, try to build your own 
validation example. I'll be working on updated docs, so they correspond 
to this prototype.

Henrik - generally - do we have per-field validation, or per-form 
validation? I e.g. don't like systems, which lock me inside a field, 
untill I correct it. I hope it is the latter :-)

Both, afaict from the source.

The scope is whatever you want to validate, whether it be a field 
or a whole form.

And it won't lock you in the field, it just indicates it's not valid. 
So you can tab around like mad but the save button might not be enabled.

BTW, it's subtle, but if you make mistakes and validate, the validation 
will automatically focus the first field with an error in it.

So, it will both support Robert's method of a disabled save button 
and one that only validates at the end.

What I hate most about validations, is sometimes their strictness. 
I would break anyone's hands, who pushes me to write a phone number 
to some "standard". The phone number is used by humans anyway, and 
even then, it can be still parsed even by automat. My number is +420-777-172 
171 .... I choose my own format for the readability purposes, and 
I hate, when the form blocks me :-)

well, then you don't have to use it. validators are made from the 
user's perspective using the MAKE-VALIDATOR function to fit any format 
supported by the style to validate.

Must have selected value

 in item list 1, but doesn't mark a non-selection as invalid after 
 marking a selected item as valid and deselecting it by clicking in 
 the list-view somewhere below item "3".

This looks like great progress Henrik.

ChristianE, ok, bug in TEXT-LIST.

Gregg, thanks. There will be another iteration as new ideas have 
come up.

Henrik - question to your site being down on ML. I know that it is 
now available via IP address, but dunno if you want to get it published. 
Feel free to answer on ML.

hrm... I responded and it showed up on the list, saying that my mail 
address is blocked due to spam. Did it show up?

it did not show-up yet ...

Henrik - as for validation example - Numering required panel, 'f8, 
I have no value there, yet it shows positive validation ...

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