World: r3wp

on-draw: [
	material: get-facet face 'material
	frame: face/state/frame

	; change shadow, gradient and edge color

	face/facets/shadow-color:	select material/shadow frame
	face/facets/surface-color:	copy select material/surface frame

	; create average area-color

	foreach [c: color offset] face/facets/surface-color [
		change c average-colors c/1 face/facets/area-color
	]

	arg ; return draw block
]

This is the code to alter parameters for the draw block.

And that's all that is needed.

so in face/state/frame, there are different draw blocks for each 
"frame"?

draw: [
	; shadow
	pen false
	fill-pen shadow-color
	box 0x1 (area-size + 0x2) 3

	; edge
	fill-pen edge-color
	box 0x1 (area-size + 0x1) 3

	; background
	grad-pen linear 0x1 1 (area-size/y - 1) 90 1 1 surface-color
	box 1x2 (area-size - 1x0) 2
]

The single draw block for BUTTON.

So... very little code needed. Some words are referenced in FACETS 
for the style.

OK, button - how does it solve, over, and down/up differences?

Pekr, no, face/state/frame is only a word, like 'up, 'down, 'over, 
etc.

Pekr, this is done by altering the fill gradient. What you see is 
simply using different gradients for different states for the button.

The "geometry" of the button is fixed.

So really only one draw block for all possible states? I think it 
might not be sufficient for more complex styles/skins, e.g. animated 
states.

Pekr, we'll see how that works later, when I get to build a small 
DRAW editor.

So - how do you add focus, or disabled state to button? By just changing 
gradients? Disabled - maybe, but focused?

We will see, so far it seems good for basic styles, but really simplified 
:-)

thanks for code examples!

I've not yet studied focus or disabled. We'll see later how that 
is handled.

'Fontize doesn't grab me on a first reading either. Carl always thinks 
hard about words, so he may have ruled out 'stylesheet and 'fontsheet 
system, or something like it. Not sure how ize-ing things will work, 
be he may have.

>> 1134903170 + 1836311903
** Math Error: Math or number overflow
** Near: 1134903170 + 1836311903

Hey guys, does anyone have any idea why rebol wouldn't be able to 
add those two numbers together?

My friend Abe challenged me to write a simple recursive fibonacci 
sequence and on the 46th iteration the program quits because rebol 
can't do that calculation. I tried it on Linux rebview and rebol/core 
and on windows vista rebview even without running my script. The 
strangest thing is that rebol can add much larger numbers, but just 
not these. Does that make any sense? try the equation in a rebol 
terminal yourself and see what I'm talking about. Very strange.

Max integer is

>> to-integer 2 ** 31 - 1
== 2147483647
>> 1134903170.0 + 1836311903.0
== 2971215073.0

We see, your result is larger.

But why doesn't it coerce to decimal automatically, as it does for 
larger numbers? 

Wondering why I've never seen this.

Thanks Geomol. That makes perfect sense. Should I be using decimal! 
instead?

Becuase of 32-bit.
>> to-integer #7fffffff
== 2147483647
>> to-integer #80000000
== -2147483648

If you use decimals, you can have larger numbers, before you loose 
precision.

Up near
>> 2 ** 49
== 562949953421312.0
>> 2 ** 50
== 1.12589990684262E+15

Why was I sure REBOL coerced the result in this case? Hmmm.

I don't know. :-)

I often forget the math rules in REBOL too and just have to check.

I just tried "1134903170 [decimal!] + 1836311903 [decimal!] and that 
didn't work either... how can I get througth the "addition" barrier?

People use integer! rather than decimal! because they don't want 
to lose precision at all, rather than eventually.

Matt, do this:
    (to-decimal 1134903170) + (to-decimal 1836311903)
or this:
    1134903170.0 + 1836311903.0

Thanks, now my script should work perfectly.

If you write a number without a decimal point, it's an integer datatype. 
With a decimal point, it's a decimal datatype. You can use either 
in many functions:

>> for i 1 2 1 [print i] 
1
2
>> for i 1.0 2.0 1.0 [print i]
1.0
2.0

Rebol[]

fibonacci: func [{Makes a list of fibonacci numbers and stores them
	to a block called fibonacci-block.} loops [integer!] {Number of 
	iterations to run}
	] [
	fibonacci-block: [0.0 1.0]
	count: 0
	loop loops [
		addend-1: index? back back tail fibonacci-block
		addend-2: index? back tail fibonacci-block
		new: fibonacci-block/(addend-1) + fibonacci-block/(addend-2)
		append fibonacci-block new
		count: count + 1
		print count
		print new
		]
	Print fibonacci-block
	write %fibonacci.txt fibonacci-block
	unset fibonacci-block
	halt
	]
Print "Type fibonacci [# of loops] to make fibonacci-block."
halt

Thanks to all all of you my script works perfectly now. :-)

:-)

In the DocBase page for GUI_Panels, Carl wrote


A group has no backdrop or border and arranges horizontally by default.


I feel this is ambiguous; do groups have no backdrop or border ever 
or only by default?


I'd like to edit the wiki to make this more clear but I can't tell 
 from the rest of the page whether a panel can have backdrops and 
borders. Can anybody with access to R3 clarify this?

By the way it looks a lot like a Java GridBag.

I'd imagine that's the distinction between Panels and Groups?

So you think that a Panel is an invisible container?

I think adding integers used to produce a decimal, when it overflowed. 
There were problems caused by this, and discussions followed, so 
it was changed to the current system.

Peter, I also think that, as Chris suggests, borders are designed 
to be invisible, while panels can be seen.  I don't see any reason 
why a border couldn't be restyled to be visible, though. It will 
be one of the first things I'll want to do - hacking if I have to.

From re-reading the Docbase page, it seems that both panels and groups 
may be visible as they have styles:


Panels are implemented with the panel and group styles. You will 
use these two styles together to create a wide range of layouts.


I don't think that I'll try to clarify the DocBase entry just yet 
though.

They /are/ styles, both.

Henrik, so far this looks exactly just like VID3, except that there 
is no separation between look and feel.

Gregg, I think what you remember about coercing to decimal is that 
if you type a number greater than maxint it gets loaded as decimal.

>> type? 2147483647
== integer!
>> type? 2147483648
== decimal!

Gabriele - your desing used and combined multiple gobs. What we can 
see so far is the one gob design, plus gob style face being placed 
upon it. If we use only one draw block for various states, I wonder 
how do we do conditional drawing in one single draw blog - e.g. focused, 
vs normal state.

IMO instead of adding additional styles, we should be sure, that 
we can easily express such things as focusing, display of accelerator 
keys, etc.

Is it really one gob with a gob style face placed upon it? Isn't 
even something as simple as :
panel [
  button "Start"
  button "End"
]

at least 5 gobs?

Peter - I am talking about one single style, not multiple styles 
being one gob.