World: r3wp

stylize kind of sound natural to me english-wise, but maybe I am 
just used to it. Fontize breaks my ears :-) What is next - drawize, 
effectize? In such case I am maybe more inclined to make-style, make-font 
kind of naming.

interesting that for fontize, we can see centered: base [], whereas 
new styles are not created with base, e.g. circle example. I already 
reported it to Carl, that it is not obvious, where does area-size 
come from, as stylize block does not suggest that circle is being 
derived from some base style in the background ...

Henrik - as I think about it, you might be right. Maybe we would 
like to combine fonts, drawings, effect as more complex styles, independently 
...

Henrik - I would like to ask about your default skin plan, as you 
seem to be the one, who is gonna make it for us? Have you noticed 
Carl likes iPhone kind of interface? Will your skin effort be going 
that way? Some Flash components on the web follow that pattern too. 
I also noticed, that apps like Adobe LightRoom and now even Bibble 
Pro go similar route too .... grey, but colorful ...

example - http://bibblelabs.com/products/bibble5/

I would like to know, what ppl in general here find as being a nice, 
but still practically useable skin ....

I make most of my decisions from how physical buttons, knobs and 
materials appear, how light affects them and try to approximate that. 
I don't have a plan for the finished look as I prefer to make things 
up as I go along and look at the whole thing when it's done to see 
if some parts don't fit together. Then I change the remaining parts 
until they fit together. But the point is not to approach it as a 
physical device as a whole, like this:


http://www.synthtopia.com/content/wp-content/uploads/2008/02/nusofting-drum-machine.jpg


It's only to help discern between different types of widgets in an 
interesting and recognizable way. Since the beginning of MacOSX, 
I've looked at their UI and wondered what materials it would take 
to build their user interfaces, if it could be physical. There seems 
to have been careful thought about physical appearance or they actually 
built a real physical model of the user interface as a starting point. 
I think that's one part of what makes it interesting and attractive 
to look at.


Before OSX, UIs were largely either like the drum machine or they 
were mostly cartoony symbolic abstracts of real life elements, like 
AmigaOS, Windows or early MacOS. The original VID fits under that 
category too.


With the VID3.4 skin, I wouldn't mind if a button reminds you of 
the button on the photocopier or on the dashboard of your car in 
a realistic way, without being impractical.

not sure if we necessarily need to look at user interface that way 
(comparing to real life interfaces), but interesting pov anyway. 
Real-life does not necessarily mean attractive and cool, eye catching. 
E.g. latest AmigaOS 4 is plain ugly and not pleasant ...

Real-life does not necessarily mean attractive and cool, eye catching. 
E.g. latest AmigaOS 4 is plain ugly and not pleasant ...


Well, it is exactly opposite of what I meant. :-) OS4 is a cartoony 
user interface. I don't know where they started from when they designed 
it.

Henrik - when thinking more about 'fontize ... if also 'draw or other 
aspects are going be done this way, aren't we talking about 'frame 
concept Carl later removed? While I wonder about usability of such 
reusable text styles (are they really reusable across the styles?), 
I currently don't understand, how, without frames concept, Carl solves 
different states? Imagine button being - enabled, disabled, focused, 
not focused, over, stuff-being dragged over button, etc. How is one 
draw block supposed to distinguis it?

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