World: r3wp

There were really no artists on the Amiga team originally (or later 
for that matter).

The UI was designed by simply doing the least possible, and using 
"code" to make art.

Reichart - but users jumped in and provided UI with some nicer looks 
(e.g. Magic WB). By nowadays standards, Amiga OS was, well, ugly, 
but do you remember Windows 3.1? :-) If VID3.4 is skinnable, users 
can come with different skins too ... (although not sure it will 
happen - excpet Henrik and Chris we currently don't have artist amongst 
REBOL users ... at least I do not know of anybody suitable for the 
job)

(I was simply answering just Henrik's last question)

Anyone can make a UI (just look at the billions of Linux distros 
out there), but really few can make a lasting, memorable, useful 
and beautiful UI.

Reichart, as far as I read, they tried to make it work on the worst 
possible TV set they could find, so that's definitely a factor for 
the original color choice. But I wonder if they grabbed the look 
for OS2.0 and up from NeXTStep.

Nice second video, Henrik :-) Is there being an 'over effect? If 
so, it is very mild, first time watching the video I did not notice 
anything ....

yes, it's perhaps a little too mild. there is also a bug with 'up 
not being followed by an 'over, but Carl is fixing that.

The nice thing about the states is that I don't need to code them 
up manually for each style. Carl takes care of that and I just have 
to make the graphics for each state. Almost as good as having frames.

no need for all that hacking as was necessary with FEEL

I think that the skin strategy should be to make it easy to make 
and apply skins, get Henrik to make a good default, and then let 
third parties create good new ones. There are whole web communities 
devoted to reskinning apps - if we can make a skinning infrastructure 
that appeals to them, we win.

yes, I can definitely see different skins for different purposes 
or environments.

Making the GUI more skinnable without much programming knowledge 
would be advertisement for R3. Every new skin put on one of the skinning 
sites gets the R3 name out there - viral marketing.

Henrik - that is interesting. I asked Carl several questions privately 
(waiting for replies), and one of them being, if frames concept should 
not return back? Where is different states being expressed? All I 
can see is only single draw block? Single draw block using dynamically 
only some facets is surely not enough to express states like - enabled, 
disabled, focused, over, dragged-over, up, down, etc.?

Pekr, having a single draw block is why they are not really frames. 
All that happens is that a state is stored as a word, in this case 
'up 'down and 'over (as far as I've observed) and then you make the 
necessary modifications to colors or other parameters to the single 
draw block. This happens inside ON-DRAW.

I'm going to post a bit of code now. The word FRAME does appear in 
it, but this appears to be from a previous version which was frame 
based. Carl has not yet come up with a new word, so don't be confused:

on-click: [ ; arg: event
	face/state/frame: arg/type
	draw-face face
	if arg/type = 'up [do-face face]
	none
]

This is where we save the state and draw the face.

State as word? Do you mean in face/state block? What if you want 
e.g. focused state to be drawn by glow effect or some animation should 
be made? Imo having single draw block is not sufficient.

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