World: r3wp

robert, if i understood correctly, area-size is the size of the area 
you can draw into, size is the size of the whole face. in the examples, 
area-size: size - 2x2 (or something like that)

http://rebol.hmkdesign.dk/files/r3/gui/001.mov

Framerate is about half of what it really is.

nice ...

like Ashley's tour.r

but with animation ( sliding faces )

Carl is TV guy, he likes colorful designs :-) Buttons with shadowed 
text are not pretty :-)

In GUI_Basics chapter, in Opinion survey example, there is 'group 
used without explicitly stating number of columns. How does such 
group know, how to layout its elements? Is it simply laying all elements 
in one row by default?

Yes, one row.

What is: panel 80.200.180.80? Color with alpha?

Is there english word "pastel"? That is how current skin should be 
called :-)

yes, alpha

uh, pity it can't be solved some other easy way. I don't like implicit 
arguments, as from stylize source code nothing implies, that there 
is any such variable available:

            on-resize: [ ; arg is the size
                face/gob/size: arg

Isn't  there a typo?

    faced: [
        bar-color: teal
        bar-size: 1x1 ; modified by the progress % value
        bar-fill: ; generated from bar-color option
    ]


What is going bar-fill to be set to? It is last element of the block, 
and if you do object from it, it should have some value to be set 
to, no?

it's not a typo, but I don't know yet how that works.

the implicit argument?

Graham - what are you asking?

nothing

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)