World: r3wp

and the programmer must be able to set the starting data (used too 
to set the data type) set the increm/decrem value and set a max limit 
;)

max limit can be used to automatically calculate the size of the 
data showing part of the spinner

data type can be used too in some case for that (like date) this 
way we free the programmer to have to take in charge the spinner 
sizing

Ashley, I am not sure I like name of rebface. I think it would be 
better just as face (ctx-rebgui/face). I don't see the need to distinguish 
so much from standard View face. Indeed, I think it will make porting 
code a little slower.

That's just an initial impression. I will see if I get used to it 
nicely or badly :)

I have a working SLIDER with proportional dragger and page clicking.

do http://www.lexicon.net/antonr/rebol/rebgui/demo-slider.r

(you will need to modify demo-slider.r to point to your rebgui installation 
directory)

I am thinking of integrating arrows as options in the slider. This 
means a scroller would just be a slider with the arrows option. But 
this violates the rebgui principle of each widget being self-contained. 
However, the case for code reuse here is very strong, and so I want 
to do it. Any comments on that ?

If you do decide to integrate arrows in the slider, I hope you have 
a "smart'" arrow option like the one the one that Mac OS has provided 
since OS 8.6.

It's a big improvement on the standard up arrow at the top, down 
arrow at the bottom.

Anton, rebface word only comes into play during widget creation; 
all other references to face (e.g. feel, focus, etc) have not changed. 
In fact, that was one of my motivations for introducing it ... I've 
seen far too many people tripped up by code like the following:

	engage: func [face action pos] [
		...
		insert tail blk make face [
			...
		]
		...
	]


where the "make face" should have been "make system/standard/face". 
When a RebGUI widget refers to rebface it is now unambiguous that 
we are not referring to a face argument nor the global face.


Looking at your demo slider now. If slider / scroller can be combined 
without a net increase in code size then I'm all for it as they are 
functionally and stylistically similar (vsplitter and hsplitter were 
combined into splitter for much the same reasons quite a while back).

list-view has been updated to comply rebgui 0.30 can be found here 
http://www.rebolfrance.info/articles/regui-cooking-widgs

(click on list-view in the table)

** Script Error: Invalid path value: rebfaceeither
** Where: wake-event

** Near: show-data ctx-rebgui/rebfaceeither none? face/data [true]
>>

typo I guess

Can the list-view be resized as well when the window is resized?

** User Error: RebGUI requires View 1.2.124 or lat
er to work.
** Near: to error! :value

system/version

1.2.55.3.1

which is much lower than 1.2.124

see here for latest builds

you can pass link ?

http://www.rebol.net/builds/

which rebol do to choose ?

http://www.rebol.net/builds/031/rebview1212531.exe

About spinner, why not introducing a drop-scroller style.

It looks like a drop-list (right arrow), but while clicking, an horizontal 
scroller appear under the field. You can use arrows to up/down or 
scroll bar to go fast or to the top/bottom limit.

GRaham sorry I don't notice your masage on list50 bugs ... those 
issues have been fixed later today and I repost it under same name 
so just redownload it ;)

Just took a look at Tour.r again.  I must say I'm amazed!  this is 
really good work!

and could be even better if we have a largest use of draw/AGG for 
menu popup scroll down animation

WRT Spinner, I prefer three buttons, Up, Down, and a middle button 
the pops up slider like DideC suggested...

And yes I do use those...

Problem with 3 buttons is that they are small !

(I use something like that in Paint Shop Pro)

Yes, that can be a problem at times but they've always worked pretty 
well for me...

Yup, that's where I got the idea...

or many other draw effect exploiting capabilities of AGG

Another possibility is to put the arrow buttons side by side

now AGG it's official and it would be very cool to use it lightly 
but cleverly to make a sharpen and diferenciable set of widget ...

AGG is fine, but is for rendering something in a face.

You can imagine having only one face and drawing all the UI with 
Draw commands, but you will need to put a BIIIIIIIIIIG function in 
window-feel to handle all the user inputs  at different xy mouse 
positions !!

I'm thinking for example of transparent popupmenu in menu style of 
Cyphre this is an other example of how we could use draw/AGG to enhance 
RebGUI global interaction

DideC My idea is not to make rebgui complicated but only to make 
it wither but thinking of it the scrolling down effect can be made 
without AGG in fact

What I dislike in "current" release (1.3) is that there is two rendering 
engine: one for 'effect and one for 'draw. So you have capabilities 
(ie: better alphachannel handling) with Draw that you don't get with 
'effect.
So to make a more than 2 colors gradient, you need Draw.
I hope that 1.4 will fix that

yes but maybe that's due to a background need

because carl things that effect needs are differents than the draw 
one ...

I don't thik he takes the time to make 2 engine and one poorer than 
the other one only for fun ;)

for modern and glued-into-os apps, it would be handy to have "translucent" 
top-most window, what do you think?

Great, but remember that translucency only works on Win2k and above 
on Windows, and the situation is even less consistent on Linux. Should 
work on Mac though.

Peter, what do you mean by "smart arrow" ?  Arrows together ?  I 
was planning to add that option anyway.

Ashley, your argument has swung me to your point of view. The only 
thing is I would prefer rebgui-face instead of rebface, just to be 
totally unambiguous.