AltME groups: search

when you meke a click on the grad button the event offset retrived 
is related to the 0x0 and Maxgrabbutton_xxMaxgrabbutton_y so you 
need to make a convertion algorithm to make this event/offset value 
related to a position on the grabbutton/parent-face and in this process 
you lost some précision.

I give the closest solution to the perfect one but to say you the 
truth I'm not a VID guru I only try to adapt the calculation made 
by Carl into his scroller VID  widget. But has the construction of 
the REBGUI scoller/slider widgets are different from the slider/scroller 
VID ones that explain why there some knobing effect :).  But I think 
we have 90% of the method and for a VID guru solving the knobbing 
effect is jut a question of spending like 3 minutes on the problem 
;)

Ihave an other example of those related calculation method with the 
toc-panel in MDP-GUI and MDP-Viewer. When you click on an entry in 
the toc you have in the viewing pannel the title that appears in 
the middle of the viewing pane and not in the top of the viewing 
pane ...

the effect I gey is title on is well well displayed and more we advance 
in the title more we have them showed on the bottom of the viewing 
pane... it's like a falling effect ;)

I tryed a port for MDP-Viewer to RebGUI system and what I can say 
is that lot of thing are missing...

Most of this is [hopefully] answered here: http://www.dobeash.com/it/rebgui/


While VID provides a nice set of styles to work with, RebGUI aims 
to provide a rich set of [functionally complete] widgets to work 
with. The specification syntax of RebGUI is similar to that of VID 
as:

	1) They are both built on top of View
	2) The VID specification syntax is near optimal

 3) I wanted to be able to swap between View / VID and RebGUI coding 
 without *too* much of a mind-set change!;)

yep and we have to keep in mind that VID is about 5 years old and 
rebgui is about 2 month old ;)

As Shadwolf has done a super job to get the MDP-Browser (that's how 
I want to name it) done, based on Ashleys base, I want to playback 
the result to the community. And IMO we should take this project 
to stress-test RebGUI because it's quite complex.

Latest build available at: http://www.dobeash.com/files/RebGUI-023.zip

Highlights include:

	- Changed default font from "Arial" to "Verdana"
	- Added label and table widgets
	- Added window-level 'do block support

 - Added 'reverse keyword to support windows style right-to-left widget 
 placement
	- Renamed set-title to show-title
	- Merged %request-file.r into %requestors.r
	- Renamed %gui.r to %rebgui.r and prefixed other files with same

Read more about these changes here:

	http://www.dobeash.com/it/rebgui/display.html#section-2.2
	http://www.dobeash.com/it/rebgui/display.html#section-3.3.2
	http://www.dobeash.com/it/rebgui/display.html#section-3.4
	http://www.dobeash.com/it/rebgui/display.html#section-4.3
	http://www.dobeash.com/it/rebgui/display.html#section-5.15
	http://www.dobeash.com/it/rebgui/display.html#section-5.26

Tree code must include the capablity of seting node and leaf icons 
 ;)

could be great to have a spread sheet on every missing widget and 
what Ashley want to see in them this could leads our devs

The table widget looks a bit strange here in that at the right side 
I see a blue area between the last column and the slider.

Odd, I don't see that here. What platform and View version? Screenshot?

I have this with 0.2.3 and when resizing on x axis on the right

Actually, locating rebgui is a problem.  How does a script such as 
the above get the latest distribution and unzip it ?  I would prefer 
the rebgui files to be uncompressed (or compressed using rebol, at 
least) and there should be a standard way of determining the latest 
version.

So a script should be able to check for the latest version and download 
it into the public cache (which may be successful or not, depending 
if net connection is available), eg:
	do load-thru http://www.dobeash.com/it/rebgui/get-latest.r
and then just
	do path-thru http://www.dobeash.com/it/rebgui/rebgui.r

to initialize (which automatically falls back to any previously cached 
version).

Another issue:  Excuse me if this has come up before..  

The archetypal View face has some of its facets set to none, which 
makes using VID styles alongside RebGUI more difficult (because the 
VID-based styles are not expecting those facets to be changed.)

Suggestion: create widgets/rebgui-face and encourage widget creators 
to make from that.

And now a question:
	widgets: make widgets [ my-widget: make face [ ... ] ]

the best (or only) way to add your widget to rebgui, making it available 
to DISPLAY ?

mixing vid with rebgui has also some api-problems. some i found:

 /action: has in vid this args: [face value]. value is something usefull, 
 like area/text, slider/tdata, first text-list/picked etc. maybe its 
 not needed, "value" saves not much to "face/text". but supporting 
 that arg would be compatible

 /init: in vid this is a block and 'done. in rebgui it is a function. 
 vid has the advantage that init can be easily extended in substyles, 
 just add to it. rebgui has locals because it uses a function.
 /init2: not called by vid. 

resizing: not in vid, but one could write a /resize and plug it in 
the vid-face.

also there are some global changes which may break other things (removing 
event-func and changing global face IIRC).


If there is interest in making such small changes, i would help with 
making the rest compatible. adding #xh - parsing to 'layout and such. 
for "keep small" rebgui could have a "load-time-flag" to decide about 
using vid-stuff or all own.

What i would really like is rebgui for complex style-building (area 
with slider etc). this is closer to raw faces. and vid for quickly 
writing "pages", IMHO it has a rest of advantages there. (maybe not, 
i am a rebgui-beginner).

I already did ;-) and got it mostly working. but not that straight 
forward as I like to see it.

Anton

 1) Design decisions: thanks; if you think any of them were *bad* 
 then let me know, that's the reason it's still alpha ;)

 2) I like the edit-pair demo, I'll look at adding a cut-down version 
 of it to %tour.r

 3) Versioning / caching was something I was going to look at once 
 RebGUI goes beta and / or we have more of a handle on how REBOL/Services 
 works.
	4) "local" face definition: good point, added to next build.

 5) Extending widgets object: Yes, RebGUI doesn't have a "stylize" 
 system so you have to extend the widgets object when you need to 
 add your own. My hope is that with a functionally rich set of widgets 
 this will be the exception rather than the rule!

Robert

 Action handler not yet added to table widget. I'll add odd/even coloring 
 to the ToDo list.

Volker

 [face value] - less important for RebGUI as face/text or face/data 
 covers almost all cases; but I'll think on it a bit more as the compatibility 
 aspect is worth considering.
	/init - I'll look at making this a block in the next build.

 event-func removal - I'm considering a "load-time-flag" as you suggested
	system/standard/face - as per comments to Anton above
	"If there is ..." - agree fully with everything stated here ;)


RebGUI development is taking a slight pause until View 1.3 is released, 
as I want to baseline against that and remove all the pre-1.3 exceptions 
that have crept in.

What's the time line on focus and tabbing between gadgets?

Ashley, I had also wrote a VID integer-edit style, then I decided 
to make a single function to generate pair, integer and decimal-edit 
styles. I could convert this in future. It kind of violates your 
"each widget self-contained" design feature, but the code shrinkage 
was too hard to resist, and the potential is there to support more 
datatypes...

5) Extending widgets object:   I was looking for a doc to show how 
to create the simplest widget ever. If you are happy keeping it this 
way (ie. "do it yourself") then I could write the example script 
and accompanying doc, to add to the Widget Designer's Guide.

... simplest widget ever ...
 How much is there to write about?

	widgets: make widgets [my-widget: make face []]

Or am I missing something? ;)


Your VID edit styles sound interesting, but I'm looking for a more 
universal solution to "field input masks" and "field input validation". 
Something that would let me define a telephone number mask for example.

some thing like a ###-#### for fone number for example and ??##??? 
for 2 strings followed by 2 number then by three  strings

rafinement could be a coded like mask like 3#-4# (for fone number 
mask ) and 2?2#3? (for the 2chars then 2 number then 3 chars mask 
)

so ? = what ever a to z ot A to Z character and # = What ever 0 to 
 9 char all other caracteres  in it are considered as always needed 
 things. Repetition can be simplify be using numbers in the mask

when an entry doesn"t feet to the mask a message must be displayed 
showwing and automated example of what must be a good entry to warn 
user :)

Hm...  You must be in france and Google's france branch must be redirecting 
you differently...

Ashley, very nice work. I have probably asked everyone in this group 
at one time or another about how VID works (or doesn't seem to). 
I really appreciate that you are working on something like this. 
I had all but given up trying to get my interfaces to function the 
way I wanted them to. At some point one has to just give in and focus 
on the actual program. Now I'm thinking I can have my cake and eat 
it too. Thanks big guy.

Latest build available at: http://www.dobeash.com/files/RebGUI-024.zip

Highlights include:


 - New edit object / feel added in a separate file, %rebgui-edit.r

 - Documentation on above at: http://www.dobeash.com/it/rebgui/edit.html
	- Face redefinition localised to widgets object
	- Radio-group color toned down from green to leaf

Known issues:

	- auto-fill broken for the time being

 - edit feel needs to support tab / shift+tab into and out of "grouping" 
 widgets

 - cursor down goes to end of text instead of next line?! (yell if 
 you know the answer as I'm stumped on this one)

On the drawing board

	- area widget needs a scroller added to it by default
	- field format / validation masks
	- inline spell-checker

ashley I'll take a look at auto-fill on the weekend, and try and 
get it to behave like the VID version does. anything to look out 
for?

with rebol/VM 1.2.116.3.1 and windows XP SP2 ( i don't experiment 
those bugs by my own there where submitted in the Form of rebolfrance.org 
website by cr8825.)

Regarding use of color in RebGUI:


I don't think color choices for LEDs in RebGUI are good, which is 
namely because the default colors are red and green.

That not only excludes the color blinds, but even the red-green-blinds 
(sort of lesser color blinds), which applies to even more people 
(mainly male ones). 


Using blue and yellow would make things slightly better, but would 
still be a hurdle for full color blinds. Probably different shapes 
would be more usefull here, as they'd give an additional clue.


And, finally, the colours are named wrong in the LED group: check-group 
60x4 data ["Red" true "Green" false "Blue" none]

Believe me, I had to measure the valve values to find that out ;-)

And personally, I find the visuals of the sliders and draggering 
irritating, too.


The gradient in the sliders container IMHO doesn't integrate in the 
overall RebGUI appearence - since it's (button left aside) nearly 
the only pseudo-3d effect - and the visual contrast between dragger 
an container IMHO isn't very strong. I usually find me clicking in 
the container when I expected to grab the dragger.


The gradient in itself is somewhat unsual, too, since it makes the 
container appear standing out of screen, if one assumes that light 
falls from upper left corner (which is how most pseudo-3d screen 
elements are designed).

I second Christian's thoughts on the dragger and gradient.  I also 
found myself reaching for the gradient section thinking it was the 
dragger.  Because it has more graphic detail, it attracts the eye 
first... that should be left for the dragger/button itself in my 
opinion.  The background of the slider area should be flat.

Yep. And the current style doesn't fit to the rest of RebGUI.

I think the slider and scroller were quite quickly implemented and 
are not expected to be perfect at this stage. Having said that, I 
am now wondering if anyone else is working on new ones. It's the 
scroller widget I noticed yesterday needs some work and I thought 
I might contribute a new one.

By all means, please do. With regards to, "... wondering if anyone 
else is working on ...", I am in the process of putting together 
a dependency / project plan that shows how everything is related 
and what stage each widget / functional area is at (along with who 
is currently working on it). It's the first step to a more cooperative 
development model, but I'll implement it as a static web page until 
REBOL/Services is out.

Ok, so I'll do slider and scroller.

Here's another issue:
rebgui 0.2.4 defines a new global word 'edit

  This interfered with my custom edit function, which I use to launch 
  my favourite editor.
  I'm not changing it for you ! :)

  This is an example of the problem of adding words to the global context 
  without doing
  an environmental impact study first.

  The user should be given the choice whether to export your words 
  to the global context or not.
  But probably most of them don't need to be out there at all.

  My advice is to add only these words to the global context: [

 ctx-rebgui display show-text show-data show-title splash request-color 
 request-date request-file
  ]
  
  --- rebgui.r ---
  
	CTX-REBGUI: context [

		...

		edit: none
		widgets: none
		requestors: none
		display: none

		foreach [word file][
			edit		%rebgui-edit.r
			widgets		%rebgui-widgets.r
			requestors	%rebgui-requestors.r
			display		%rebgui-display.r
		][
			if none? word [set word do file]
		]
	]

	;if not value? 'edit [do %rebgui-edit.r]
	;if not value? 'widgets [do %rebgui-widgets.r]
	;if not value? 'requestors [do %rebgui-requestors.r]
	;if not value? 'display [do %rebgui-display.r]

	; export DISPLAY and the accessor functions to global context
	foreach word [display show-text show-data show-title splash][
		set word get in ctx-rebgui word
	]


  And each file no longer has a *named* context:

  --- edit.r ---

	REBOL [...]
	
	context [...]


  The above changes should mean few changes to the rebgui code. For 
  example, the body

  of the display function refers to the widgets context, but this is 
  still accessible
  because both DISPLAY and WIDGETS are inside ctx-rebgui.

ChristianE

 1) LED color / design choices. Agreed. Can anyone point me to where 
 this has been solved? Or suggest a design alternative?

 2) Red, Green, Blue. These were example LED titles (much like the 
 previous "One Two Three" example) *not* a statement about the actual 
 LED colors. ;) If the example's that confusing I'll change it.

 3) Sliders / Scrollers. Agreed. The priority has been to get a complete 
 set of widgets, *then* ensure each is functionally complete, and 
 *then* ensure they are aesthetically pleasing as a whole and in their 
 own right. As I'm no graphics artist, I've taken the easy approach 
 at first by mimicking what I'm familiar with: Windows XP.

The words I don't think need to be global are: [sld slm slc slw edit 
widgets requestors]
(and even the ones I have set out above I would scrutinize more.)

Excellent suggestion and far better than the approach I was going 
to use to solve this problem! ;) I'll incorporate it in the next 
build.

;	15-Mar-2005 Pascal Lefevre
	;	27-Apr-2005 Pascal Lefevre

    ;    4-Jun-2005 Christian Ensel (minor color and shape suggestions)
	led: make face [
		size:	-1x4

  effect:	[draw [pen edge-color fill-pen window-color box 0x0 0x0]]
		font:	default-font
		para:	make default-para [origin: as-pair base-size 2]
		feel:	make default-feel [
			redraw: func [face act pos /local colors] [
				if act = 'show [
                    colors: reduce case [
						any [face/data = 1 face/data = true]  [
                            [btn-text-color btn-text-color]
                        ]
                        any [face/data = 0 face/data = false] [
                            [edge-color btn-up-color]
                        ]
                        true [
                            [edge-color white]
                        ]
                    ]
                    face/effect/draw/2: colors/1
                    face/effect/draw/4: colors/2
				]
			]
		]
		init:	does [
			if word? data [data: to logic! data]

   if negative? size/x [size/x: 1000000 size/x: 4 + para/origin/x + 
   first size-text self]
			effect/draw/6/y: unit-size 
			effect/draw/7: as-pair unit-size * 3 unit-size * 2,5
		]
	]

I gave the LEDs a slightly different shape to make them look different 
from the check boxes, to make it clearer that they are informative 
only and not meant to accept user interaction.

I dropped my previous color suggestions in favour of using only colors 
you've allready featured.

The preprocessor is freely available, even to those that don't license 
the SDK. You could just have everybody use it whether they use the 
SDK or not, and have one code base.

Very impressive demo. When I run it from rebview1247031.exe, then 
I fill the  Field\Password box, like just type in lots of characters, 
as I move the cursor over the field labels, they disappear. I can 
do this to all the tab field labels.  The words wont reappear until 
I start deleting the password characters and I move the cursor over 
the labels again.

Running latest view .. and tour.r reports 6766kbs when I start it 
.. and doing nothing at all, memory use keeps climbing.  HIt 10000kbs 
at 30 mins or so before I killed it.

On GC/memory leak : the events system allocates this memory - disabling 
events stop this leak, and changing the timers rate change the allocation 
rate. The trigger to release the memory is quite high, so it's takes 
a long time to be collected. Regardless of 'stats memory usage indication, 
it seems that Windows only gets the memory back when the REBOL windows 
are minimized.

Question for the bind experts out there. Given two files (named %include.r 
and %test.r respectively):

	REBOL []

	context [
		a: "A"
		b: does [print reform ["Value:" a]]
		c: does [print reform ["Value:" d]]
	]

	REBOL []

	RebGUI: context [
		d: "D"
		ctx: #include %include.r
		if issue? ctx [ctx: do %include.r]
	]

	RebGUI/ctx/b
	RebGUI/ctx/c


How do I bind %include.r to the RebGUI context such that it can see 
'd (as the #include successfully allows).

another option is to embedd a smaller and faster "prebol" in rebgui 
and build everything on startup, then doing it altogether.

And yes, there are typos there, Windows doesn't seem to keep up with 
my keyboard.

prebol: func [code /local p f rule] [
	if file? code [code: load code]
	parse code rule: [
		any [
			p: #include set f file! (
				p: change/part p prebol load f 2
			) :p
			| into rule
			| skip
		]
	]
	code
]
; changes code, use copy/deep if needed

t1: now/precise
save %test.r [The embedded and #include %test2.r stuff]
save %test2.r [Subembedded]
p: prebol probe [Hello [World #include %test.r here] we are]
print [difference now/precise t1 newline mold p]

then in sdk
 prebol: func[code][code]
and you are done too. (not tested)

Ashley roadmap: 1) set of widget complet (what widgets are in it 
?)  2) functionnality of this set (what they do how we use them ?) 
3) esthetic of the widgets is dicted by the low people working on 
RebGUI and the nececity to make a simplier set of widgets. The fact 
that AGG was not official have make diffucut to put in line a good 
estetical consept. As REbGUI philosophy is to be light and easy  
we can't make a lot of heavy imge insertion and image drawing

for example for listview this will be: listview | multi column full 
resizable and multi widgets type support | Shadwolf | 98% | NO

the idea is that any programer taht are working on widgets can change 
the information related to his widget and for people to have a quick 
over view on the remaining dev effort and the progression of this 
work  ;)

Roadmap updated. The only thing I have left to do is fill in all 
the "Features" and "To Do" entries, which I need to think on for 
a while.


shadwolf: Good work, you can get the complete widget set from the 
updated roadmap (table 3.4). With regards to the DokWiki ... build 
it and they will come, but you may want to refresh folks memory (mine 
included) with how to register / access (point form summary). Also, 
it's not just widgets that need more work ... localization could 
do with some native language assistance. ;)

No need to register to post .. Well it's better that's sure ... So 
to register go to this page http://www.rebolfrance.info/rebolfrance.info?do=register
you fill the form with login, Real Name and e-mail.

* Open rebol console and type :

print next lowercase mold checksum/method "mon-password" 'md5

    * Then send an email to [webmaster-:-rebolfrance-:-info] :
          o Utilisateur:  nickname (registred one)

          o Password: {9c3f8c1d181f8d7c4d2919d801943c51} (can be the raw password 
          too)
          o Nom complet: Real Name
          o Email: [mon-email-:-mon-serveur-:-com]

Ashely you can make a link betwin the roadmap and the dokuwiki wiki 
this way you give too people the complete information ;)

1) dokuwiki link: will add.

2) spanish.dat: thanks, excellent work. Added to next build and roadmap. 
Anyone for German? Robert?
3) tabpanel with scrollable header: low priority.

4) global event system: more information; what is the requirement?

run trhu on-line translators and you are done :-)

(*possible* way, I should say. I haven't tested that, and it needs 
bind in ctx-rebgui 'self.)

Ashley, I was trying to reduce the number of variable references, 
eg. in my last (possible) way, there is one instance of EDIT and 
two instances of the filename. In your last way, there are three 
instances of EDIT, and two instances of the filename. Anyway, I agree 
it's easier to understand.

what about lists, and clicking anywhere else - it should close opened 
list, but it does not, only escape works ...

Ashley, I just encapped tour to try it out, and noticed the lack 
of a 'within?

I've also added a simple text-list widget (Robert) and fixed the 
strange table render problem (which you can see be increasing the 
horizontal width of the window *before* going to the "Table" tab 
for the first time).

action select key and cursor key ?

How about an ok-button which has "Space" and "Return" keys mapped 
to it (assuming nothing else has focus), and a cancel-button / close-button 
widget which has "ESC" mapped to it (assuming nothing else has focus)?

keyboard support is really important. RT will have to be supportive 
here though, and improve keyboard handlers. I don't agree with what 
Holger stated in the past, that they need to allow only keyboard 
events, which are cross-platform. We want key-down, key-up, alt, 
ctrl tab and other events too ...

as for more complex styles - they need to work. I can imagine even 
"focus nesting". Imagine few fields, grid and buttons on screen. 
You e.g. press arrow down to move to next fields, and once you reach 
grid, I would like e.g. by pressing enter, the focus to be treated 
in terms of the grid, so that arrows, page-up, down, etc. work in 
terms of grid only ... ESC would "break" and return focus to "global" 
level, etc.

ashkey: are you using show-popup and hide-popup? if so, just use 
the /away refinement, and don't provide a custom feel (so that the 
default one is used).

petr: key down and up are not that easy as you might imply. the rest 
is supported already.

and - why is better keyboard handler a problem?

When we programmed in Visual Objects, we could override default class 
behavior and sometimes it was enough to add some strange parameter 
to function call, e.g. -1 or -4, don't remember, and you started 
to receive also otherwise blocked events ...

Excellent! Just tried it with RebGUI and it works beautifully; even 
with global events killed. I think the edit-list / drop-list problem 
is solved. ;)

Latest build available at: http://www.dobeash.com/files/RebGUI-030.zip


*** Note that this version requires View 1.2.124 or later, and that 
the zip file is unusually large (346Kb) as it includes a dictionary 
file (future builds wont). ***

Highlights include:

	- New language, dictionary and spellcheck functionality added

 - Documentation on above at: http://www.dobeash.com/it/rebgui/edit.html#section-4
	- All objects merged into one context
	- Major code reorganization / restructure
	- Reduced number of global words to 11
	- Pre-0.3.0 comments removed
	- Pre View 1.2.124 code removed
	- New text-list widget added
	- Added show-color accessor function

 - rebface and rebfocus synonyms to avoid collision with face / focus
	- Large number of bug fixes
	- http://www.dobeash.com/it/rebgui/roadmap.htmlupdated

Known issues:


 - edit feel needs to support tab / shift+tab into and out of "grouping" 
 widgets

 - cursor down goes to end of text instead of next line?! (yell if 
 you know the answer as I'm stumped on this one)
	- focus

 - edit-list / drop-list should use show-popup/away (some compatibility 
 problems)

On the drawing board

	- area widget needs a scroller added to it by default
	- field format / validation masks
	- menu widget
	- better keyboard navigation / focus

Petr: that link times out, i'll check again later. anyway, i don't 
know win32 nor i do know how rebol does even processing internally. 
i know how key events are usually processed in various platform, 
and most applications just work in the higher level when they get 
characters, not keys.

getting keys instead of characters means a lot of new work to do, 
and i don't see much reason for rebol to do so, except for games. 
but, games will need much more than that!

ashley: testing RebGUI-030. When I click a tab in the big pane and 
then click the last pane in the sub-pane, it sometimes crashes to 
console

yes... but a different error: go to spinner tab, click the buttons 
on the spinner a few times. go to another tab in the same group and 
back to the spinner tab again. then click inside the text field of 
the spinner

Couldn't behavior of list be changed a bit? Maybe we are near? Menu/list 
should not definitely automatically hide, when you move mouse away, 
but it should hid, once you click outside. That is default and imo 
cross-platform. I wonder if we can achieve that?

If you drop down the edit list, and then edit the field,  the list 
won't collapse again.

1) menu / list behaviour - will change once I iron out a few popup/away 
compatibility issues; it will then work as expected and the quirks 
it has now (as Graham discovered) should finally be fixed.
2) text-list highlight - noted

3) table - needs further work, but getting row selection working 
is a priority

4) leds - thanks to Pascal Lefevre for the original concept and Christian 
Ensel for the latest change
5) password - agreed

6) spinner - agreed. Before I spend any time on this one, how relevant 
 are spinners to today's UIs? I can't recall *ever* seeing one used 
in any project I've been in. Any strong objections if it's ditched?

We have request-date for that. Spinners are usually used to increment 
/ decrement integers and percentages, with support for min, max and 
step values.

I'm looking at my EMR, and I use spinners on all the numeric entry 
fields, and dates .. but the truth is, although the gadgets are there, 
I have never used them.

for example Image I'm a commercial I need to set for tomorow a schedule 
with some client what would be grphically better for me ? click add 
button and then select the date user request date or Click Add button 
then use spinner to select the proper date and time and enter an 
entry to the topic field :)

Now I'm still a commercial but this time I plan a tour to East America 
in several town with several client and this trip is planned for 
2 - 3 month since now. What would be perefable use a spinner based 
interface or use a resquest date based interface

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 
;)

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

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 ?

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).

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 ;)

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...

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 ...