World: r3wp

I wouldn't use pastel to describe the color scheme.

Artifacts
 is correct American spelling, though maybe no English. :-)

*not* English.

Petr, from what I see group seems to work just like in VID3. Layout 
as row if no columns are specified.

Status: Fixing more bugs and I'm starting to work on the real skin.


So far, skinning is quite simple but not unlike VID3. It shares some 
of the same possiblities although there are certain restrictions 
in place to simplify and make it easier to understand. Unlike VID3, 
gobs are prearranged, so there is a single DRAW gob and a text gob 
on top of it and during skinning, I'm not even aware of the presence 
of gobs. If the skin does not work, the face is invisible.


I've been told to hold back on using VID until Carl has tried building 
some apps and dialogs with it to eliminate usage problems.


Pictures are trickling in on the aforementioned URL once in a while. 
:-)

prearranged gobs and plumbing of text gob over draw gob instead of 
real free multi-gob design does not sound good to me ...

So, you're calling it VID??

Graham, oops, I guess. :-)

http://rebol.hmkdesign.dk/files/r3/gui/index.rsp

Easier access to images.

http://www.rebol.net/r3blogs/0151.html-GUI: Colored buttons - Attributes 
vs Styles

Henrik - as I can see you are playing with buttons and its possible 
design - here's some comparisons from the time of View 1.3 project

 - http://www.xidys.com/rebol-screenshots/btn-comparison.jpg


I liked version of buttons from Chris, as it was kind of mild, not 
so much pastel .... just for inspiration, as I bet you have your 
own ideas :-)

the old windows style was to include an icon in the button as well.

So far the fonts are incorrect, I but am working on how to change 
the shadow type to something more appealing.

Figured it out. :-)

So how is text being implemented? Is it separate style, or harwired, 
by layering text gob upon draw gob?

That I still don't know, but I'll show you a fontize example. Fontize 
is like stylize, only for fonts.

fontize [

	base: [
		font: [
			color: black
			size: 12
			name: "Arial"
		]
		anti-alias: off
	]

	centered: base [
		para: [
			margin: 0x0
			origin: 0x0
			align: 'center
			valign: 'middle
		]
	]

	button: centered [
		font: [
			color: black
			style: 'bold
			size: 14

   shadow: [0x1 255.255.255.100] ; black shadow here. should be transparent 
   and bright.
		]
		para: [
			wrap?: false
		]
		anti-alias: on
	]

]

ignore the comment. forgot to remove it last night.

fontize? oh my god :-) why something like that is needed? Couldn't 
it be just stylize?

Fontize is quite a nice way to separate asset information for the 
skin away from the skin itself. This way you know where all font 
styles are. Besides, fonts in R3 are more complex than in R2 as there 
are more options.

It has not been decided yet, but I wouldn't be surprised if bitmaps, 
complex vector graphics and gradients are going to be handled the 
same way.

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.