World: r3wp

I know that I will be able to use it wherever I want. I was just 
trying to discover possible workflow. E.g. someone does nice Photoshop 
mock-up, and now you want to cut it down to particular pieces, for 
particular widgets. So it will mean "gradient hunting" - you will 
have to reproduce the possible Photoshop effect in draw dialect, 
am I right?

Rebolek - I do understand the process. I am trying to find out possible 
workflow, nothing more ....

btw - I expect we will not allow bitmap skinning/material? (I know 
that it does not scale)

It's not exactly in draw dialect, but yes, you're right. Of course 
there's still posibility, that you make your own buttons in Photoshop 
and just use the bitmaps.

Rebolek, perhaps post an example of one material, how the gradient 
is written by the user, etc.

Ok, this is current material deffinition (not all of them).

materials: make object! [
	; base material - normal color
	base: make object! [
		up: down: over: make object! [
			specular: 'high
			intensity: 1
			diffusion: [1 1]
			opacity: 1
			texture: none
		]
	]
	chrome: make base [
		up: over: down: make up [

   diffusion: [1.00 0% 0.78 49% 0.76 50% 0.7 51% 0.76 97% 1.00 100%]
		]
	]
	aluminum: make base [
		up: make up [
			diffusion: [1.00 0% 0.74 7% 0.70 70% 0.71 97% 1.00 100%]
		]
		down: make up [
			diffusion: [0.67 0% 0.78 7% 0.71 70% 0.72 97% 1.00 100%]
		]
		over: make up [
			intensity: 1.03
		]
	]
	; for use in container in various box styles
	container-groove: make base [
		up: down: over: make up [

   diffusion: [0.0.0.200 0% 0.0.0.255 50% 255.255.255.255 50% 255.255.255.220 
   100%]
		]
	]
]

This is combined with color and definition for draw gradient is created.

OK, nice. And then, in draw block, I expect variables being used, 
which will map particular preselected material?

yes, correct

In below code - why field does use different specs for validation, 
e.g. not using 'validate word in 'option block?

panel [
    name: field
    address: field
    city: field options [required: false]
] options [validate: [not-empty] required: true]

ah, disregard my question - 'required has nothing in common with 
'validation ....

Pekr, do you understand how it works?

Henrik, sorry to ask but where is the build information? I scanned 
back to mid-August but didn't find it.

Gregg, see august 28th in the REBOL3 group

Ah, different group. Thanks.

Henrik - maybe I do, maybe I don't. What I did not get is - why the 
stuff is not nested? I mean - is 'required parameter kind of related 
to validation stuff? If so, I would expect something like:

validate [method: not-empty required: true]


... the way it is - we  might polute 'options namespace, which serves 
also other purpose. But again - its just a note, not a complain ...

it is nested. 'required indicates that the field is required, so 
that if the field does not validate, that constitutes a fatal error. 
otherwise it only presents a warning.

btw - back to my DOS app generator (Clipper + Zachary) :-) There 
was one other interesting feature. Let's say you have an invoice. 
And you have field to enter a company. That field is validated against 
customers table. There was a validation option named 'must-exist, 
may-not-exist. That way user could either enter new value, or only 
choose from existing values. But - the customer table was not probably 
a good example. 


And then - each grid/table had options too, called AED (Add, Edit, 
Delete), plus option, if you allow ADD option caused by validation. 
Example - you enter customer name - it is not found in customer table. 
If you allow 'Add option for grid, when user entered new customer 
name, and not found, it automatically popped-up a form, to enter 
new customer. If 'Add option was not allowed, then the person had 
to call someone, who had rights to enter the data directly into Customer 
table ... well, probably confusing description :-)

the next GUI release will require A105. is it generally available?

yes.

there was a download link posted on altme... though its probably 
lost in the chat.

by lost I mean, not viewable or not obvious because it has scrolled 
up in the chat

Pekr, must-exist or may-not-exist could be done as validation, but 
unsure if it's a good workflow. That depends on each UI case, however 
you are free to design the validators as you see fit. you can also 
run mulitple validators in sequence.

Maxim, ok.

http://www.rebol.com/r3/downloads/r3-host-kit-a105.zip

http://www.rebol.com/r3/downloads/r3-host-kit-annn.zip- the nnn 
refers to the current version ...

I think robert also had a precompiled version ... or is that in the 
zip file nowadays?

I think that's 104

I think that a compiled version of each host-kit should always be 
included in every release. who will mind the few extra kb required?

Why??

cause not everyone is able to compile things, and they might still 
want to be able to test out the new features.

this way a single rebol release channel covers everyone.

These are developer releases ..

AFAIR, Carl is released untested builds ... not for the faint of 
heart

Some even say "don't know if this will compile or not"

That's the agreement we got ... in order for him to release more 
frequently

I'll switch to advocacy...

i like henrik's work so far  that's what i was talking about when 
i was asking for a mature widget set...

thanks to Gregg for a really good session on reviewing the validation 
scheme. this is precisely what I needed.

some notes:


- validators 'not-empty and 'selected are overlapping, so maybe 'selected 
should not work on blocks but simply check if the output of the face 
is NONE

- using the 'only-positive validator alone will cause a crash, if 
the input is not a number and if the previous validator is not a 
check for number values. I designed it like this to indicate that 
the value may not be anything but a number, but there is a disagreement 
over whether incorrect usage should cause a crash.

only-positive: I would expect an implicit check for a number. If 
it fails, it's not positive.

The message to the user should be: Not a number.

Robert, the idea is that only-positive does no numeric checks as 
there is another validator that specifically does this. If that validator 
fails, only-positive is never evaluated.

Hence with the correct setup, you would get a not a number error.

you can combine multiple validators in sequence for a face and the 
first one that fails, stops validation for that face.

Yes, I understand. I would expect that only-positive than combines 
two validators: is-number & greater-zero as a pre-set validator.

ok, I guess we need a way to combine validators

new build released at http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3


This one contains material system and some bug fixes. Requires A105.

view [ title "hello world" button "test" print "hello" ]

does not show the button until you resize the window

It enforces a minimum size window but only after you first resize 
it