World: r3wp

I will try to reshape my question - I am trying to understand the 
way it is implemented in. Simply put - style is recently represented 
by one (or in future by multiple switching?) draw blocks. The draw 
block draws the widget. Now - where's the place for material? Does 
it somehow overdraws the whole widget (replacing original draw block), 
or does it influence some of original draw block parameters?

the material only represents colors and gradients. it doesn't do 
anything to the draw block.

and also - does material mean a skin? Or is material system going 
to be part of even more complex/flexible skinning? Note - those are 
just question, so no offense :-)

no, material doesn't mean skin. it's only a small part of the skin 
where you can reference a pre-calculated gradient by name for a single 
part in the draw block.

if anything, inspiration was drawn from 3D modelers on how they apply 
textures and surface to a 3D model. Bolek is working on improving 
the way that materials are created and used.

ok, thanks - now it makes sense ... you can cut those few sentences 
and add them to Material System: About - section :-)

but the material (gradient) is still represented by draw, right? 
I mean - there is no chance for designer to e.g. use some gfx tool, 
to create some nice material, as it is not convertible to AGG, right? 
Or would there be any way, via SVG for e.g.?

no, the material system simply calculates a gradient block or a color. 
then you are free to use it whereever you want.

Pekr, the basic usage is this: set-material face material. Where 
material is name from list of predefined materials. Of course you 
can add your own materials.

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.