World: r3wp

As for business apps - that sounds fine, it is just that we did not 
see e.g. list of styles, you might need. Is there e.g. a tree-view? 
Tabs? Table is there IIRC (there is a screenshot on henrik's site)

You can't write business apps without these widgets .. so ... take 
it easy Pekr!

Henrik, don't you see why you're not getting any feedback?  You guys 
shut everyone out for months and now suddenly want their help with 
feedback.  Human nature doesn't respond well to such treatment.

graham, and I posted all the relevant information to validation and 
dialogs a week ago, the build system 2 weeks ago. zero feedback.

when is validation triggered? In DOS app generator I mentioned, there 
was such a functionality, that you could limit values to type - it 
was called 'vtg - variable-to-get, and it was used e.g. when you 
wanted to limit selection to floppy drive A, B values, etc. :-) Nowadays 
we have list-boxes, but I still can imagine special kind of fields, 
e.g. Date, IP field with various masks, allowing to type only numbers 
for e.g. But that would require validation being triggered on per-press 
basis ... just thinking out loudly ....

currently validation is triggered on window open to init state. then 
you can call it on the window as needed and it runs also as a reactor, 
hence every time a field is unfocused or a button is pressed. it 
also is triggered on window close, given the button that closes the 
window is a dialog button.

as for the type of validation, that is completely customizable. you 
can also scope validation, so you can say that a panel of fields 
may not be empty, by adding that option to the panel instead of each 
field.

http://rebol.hmkdesign.dk/files/r3/gui/236.png

Materials system is back in (just a quick test)

Cool :-) Cold you please say few words about the material system? 
What's its purpose, design? Is it more complex/flexible system, or 
just mostly a gradient/background replacement? thanks ....

the purpose is both to eliminate the need for fiddling with colors 
directly when creating a gradient surface for, say, a button, and 
both to store material settings, so you can switch quickly between 
them or select one for a style. so for gradients, instead of working 
with RGB values (unwieldy), you work with brightness, diffusion and 
specular.

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.