World: r3wp

Yes, that would be nice.

then switching panes wouldn't be any more complex than:

view layout [tab-view 400 with [tabs: ["One" "Two" "Three"] panes: 
[layout1 layout2 layout3]
]
]

or this is quite feasible:  layout [tab-panel "One" "Two" "Three" 
panes [ layout1 layout2 layout3 ] ]

Default size of the tab-panel is calculated as the maximum of the 
three layout pane sizes. The three texts are available in face/texts 
so can be processed by init easily to create the three buttons. PANES 
would be a dialect word that simply sets face/panes, absolving the 
need for WITH in the most often used cases.

Note that rebgui has a tab-panel with a pretty simple spec, eg:
	tab-panel data ["one" layout1 "two" layout2 "three" layout3]

good one

..

Thanks folks!!

someone wante graphing, dunno what group was it posted in - one interesting 
project using AGG and Python - Matplotlib - done using AGG - http://matplotlib.sourceforge.net/screenshots.html

Looks nice, Pekr. Would it advocate REBOL making REBOL versions of 
those examples? The code should be less, of course. Else there wouldn't 
be much point in doing it. Maybe it's possible to make a Python -> 
REBOL converter (cross compiler)? I know zip of Python, so I can't 
say.

I am not sure how universal the library is for graphing ... maybe 
if we want to do graphing, we should look for the best of kind library, 
then to port ... I am not sure if there is any advantage to matplotlib 
- it calls agg library, which we have inside of rebol already, so 
:-)

http://big.faceless.org/products/graph/examples.jsp?initial=browsershare

I see. The examples are in matplotlib syntax. And matplotlib is a 
python 2D plotting library. So, as you say, it's probably better 
to find the best plotting library (or make a new one), than making 
an implementation of matplotlib. It could be the best one around 
though.

I think, we have a problem with the way, AGG is implemented. E.g. 
arguments to LINE are pairs (like 100x100). To be able to make a 
smooth curve using LINE, the arguments have to be decimals. Try the 
following code to see:

img: make image! reduce [370x290 white]
blk: [pen blue line-width 0.7 line]

for t 0.0 2.0 0.01 [s: sine 360 * t append blk as-pair round t * 
185 round 290 - (s * 145 + 145)]
draw img blk
view layout [image img]

Yes, decimal support for pair!  I hope this comes in R3 (or sooner? 
;)

Flash is using twips, which seems to be enough.

And not just Flash - http://www.applecore99.com/api/api012.asp

Twips are screen-independent units to ensure that the proportion 
of screen elements are the same on all display systems. A twip is 
defined as being 1/1440 of an inch.

This seems more complicated than decimal pair to me, because you 
need to recompute from twips to actual pixels, so you need to know 
screen resolution and size.

I think the ephemeral vector! datatype might have been using decimals.

Geomol, don't forget you can just use a higher resolution and scale 
it.

scale: 10
img: make image! reduce [370x290 white]

blk: compose [scale (1 / scale) (1 / scale) pen blue line-width 7 
line ]
for t 0.0 2.0 0.01 [
	s: sine 360 * t

 append blk as-pair round t * 185 * scale round 290 - (s * 145 + 145) 
 * scale
]
draw img blk
view layout [image img]

That's the way how the twips works 1px = 20twips so 1.2px = 24twips 
- the scaling is done on the draw engine side so you don't need to 
scale it yourself. In my dialect i just have directive 'units twips' 
and then the interpreter know that 24x24 is equal to 1.2x.1.2  --- 
if I'm not using twips all values are multiplied by 20 and rounded 
- that's the way how it's in Flash and in my Rebol/Flash dialect

(in Flash internals - in actionscript there is not decimal pair datatype, 
what I know)

Anyway, if there will be the decimal pair datatype, I will be very 
lucky :-))

OK, so that would be more comfortable and handy.

Anton, good point with the scale. :-)

Is it possible to add effects to am image using the draw dialect 
? (ie do something like tinting an image inside the draw dialect)

yes

I think you need to use the image inside the DRAW block.

The docs arent clear on how to do it though ....

hmm... wait

I don't think you can squeeze everything into the DRAW block, but 
you can of course do it inside the EFFECT block. I do remember seeing 
in the AGG test program in the Viewtop something that let you use 
transparency on top of an image, but I'm not sure taht's what you 
want

I wanted to use the an effect block inside of the draw dialect but 
I suspect that its not possible.

no that's not possible

OK .... thanks.

The EFFECT block is like a graphical pipeline. You can have a serie 
of effects and DRAW blocks after each other. Like:

img: to-image layout [box red "Red" box green "Green" box blue "Blue"]

view layout [box 200x400 white effect [draw [image img] tint 40 draw 
[translate 100x100 image img]]]

Phil, maybe you can use this to have, what you're after?

Oldes: that's bad design that one pixel equals to twips. From the 
definition twip should be resolution-independent, so it's nonsense 
to set it to some fixed value. But I know it's not your but Macromedia's 
fault.

Gemol .... that is interesting (I understand now what is meant by 
a a graphical pipeline) but not quite what I wanted. 

I have a draw block with a number of images and I want to apply an 
effect indivdual images.

You must precompute the images with the effects, then use them in 
the final draw block.

http://www.hmkdesign.dk/rebol/tab-view/tab-view.r<-- a very small 
demo.

Small, yet very nice! Clear and cool, reminds me on e.g. the buttons 
of my old tape deck. I think you've already said it before: the BTN 
style's look is nice, but it's way too under-represented in VID, 
making typical layouts look inconsistend. This one helps.

yep, actually it was more inspired by the segmented button in OSX. 
I think it conveys a much better message of grouped buttons than 
just using TOG buttons with OF 'group

now I'm beginning to wonder how SCROLLER would look :-)

infinitely segmented button ?

yeah

now I've run into the problem with VID elements sharing the same 
font object, which means that if I create three tab views, and change 
the font in the first one, the other two incorrectly also change. 
where exactly is this fixed? I've tried putting the font object inside 
the init code for the element, but this makes it impossible to change 
the font settings from within the layout.

I hit that problem with shared para object and the fix was:

stylize/master [
	area: area with [insert tail init [para: make para []]]
]

so something similiar for font should work.