World: r3wp

check: make face [
    edge: none
    data: false
    para: make para [origin: 14x0]
    effect: copy [draw [
        pen 96.96.96 fill-pen 255.255.255 box 0x0 12x12
        pen none line 0x7 5x12 11x0 line 0x6 6x12 12x0
    ]]
    feel: make feel [
        redraw: func [face act pos][
            if act = 'show [

                face/effect/draw/9: either do face/data [255.0.0][none]
            ]
        ]
        engage: func [face act event][
            if event/type = 'down [
                face/data: not do face/data
                show face
            ]
        ]
    ]
]

usage: 
check [
    text "a label"
    size 100x15
    data true
]

another bug (or more likely unfinished part): the last widget in 
a row determines the height of the row

sorry, didn't fully read the specification - it's the intended behaviour

Latest release, incorporating all the above changes, available at: 
http://www.dobeash.com/files/RebGUI-012.zip

Documentation also significantly expanded to include:

	- Latest REBOL/View facet observations
	- Glossary of terms
	- Licencing section
	- RebGUI Display User's Guide
	- RebGUI Widget Designer's Guide

Get it here: http://www.dobeash.com/it/rebgui/


My intention with RebGUI is to foster a community project that can 
deliver a credible alternative to VID, with my role being one of 
project leader / sponsor. The licence stuff is just to clarify my 
legal position and the rights of contributors and users. I'm looking 
at how to enable co-operative development (using IOS) but this can 
wait until the base design has stabilized. It's just too easy to 
fork efforts at this stage. All of this is still Alpha so if there 
is anything you disagree with (technical, documentation or legal) 
then please raise it here and I'll do my best to accommodate your 
concerns.


I want this whole process to be as open as possible, but without 
the pitfalls of "design by committee" where nothing gets done! ;)

http://www.dobeash.com/it/rebgui/facets.html#section-5

May be you can add to the 'effect definition that any effect can 
be used. Not only 'bezel, 'bevel and so on

AShley thantk you verry mutch for you effort ;)

I have monitored  the memory consumtion of test.r script and I have 
seen that every second betwin 4 to 8 ko are allocated maybe there 
is something to do to avoid this

I think it's related with event analyse

Hum after some tests that eratic memory consumtion apears to be related 
with the anim widget ... I put  it in  comment  then I have a stable 
mémory allocation.

othe widget that consums memory is the progresse widget

progress: make face [

  effect: copy [draw [pen blue fill-pen blue box 0x0 0x0]] ; is copy 
  needed?
		data:	0
		font:	none
		para:	none
		feel:   make feel [
			redraw: func [face act pos] [
				if act = 'show [
					face/effect/draw/box: to pair! reduce [

      to integer! face/size/x * face/data: min 1 max 0 face/data face/size/y
					]
				recycle
				]
			]
		]
	]

this provoque the memory usage stabilisation it will block to the 
needed

after the draw we '"clear" the memory using recycle

same for anim adding to the feel a recycle call after the show face 
will stabilize the memory usage

COPY is not needed, though it does not hurt.

Shadwolf, the memory used increases always more and more ?

agree, COPY not needed - just an habit when I modify blocks, but 
here I did it two times wrong:
- the 'draw sub-block is modified, so it should be copy/deep 
- no 'copy needed with 'make, who does copy/deep

Anton without recycle yes but with it it's stable

mmh, after disabling nearly all widgets, it seems that the events 
who eats memory:

even without 'progress, memory is consumed by 4-8ko steps. (just 
going over 'button eats memory)
for 'anim its more visible ('time events),

recycle in 'progress mean recycle at each 'show, so a recycle at 
window level could do the same.

it could be just 'show causing the 4/8ko memory usage.

in fact I think is allacation every time an allocation is done the 
yet existing data is not cleared we yet discus this point on french 
forum we we was working on free-mem fonction

for example: face/effect/draw/box: to pair! reduce [

      to integer! face/size/x * face/data: min 1 max 0 face/data face/size/y

but for anim, it's a simple assign

no allocation is done in 'anim

the yet existing data is still in memory at it's image you yet have 
the previous one some where in the memory stack  manage by REBOL 
GC

anim: make face [
		edge:	none
		font:	none
		para:	none
		feel:	make feel [
			engage: func [face act event] [
				if event/type = 'time [
					face/image: first face/data

     face/data: either tail? next face/data [head face/data] [next face/data]
					show face
					recycle
				]
			]
		]
		rate:	1
	]

face/image is just a pointer to an image in face/data

if you use this you will see the no more memory alloc

just comment the recyle and then the memory consumtion is back ...

so there is a direct like I think

with recycle in the anim feel I get 6776ko allocated

and it's stable without it there very mutch allocation before GC 
to be called

after some play on forwar/backward icon-button I get 7600 ko of allocated 
memory without  any recycle call ...

i think 'show use some memory, and don't recycle it
it would be bigger else, something like  n * image size
I tried with bigger images (400x400 instead of 40x40)
and only 16k more is allocated at each time

Vincent in anim: face/data: either tail? next face/data [head face/data] 
[next face/data]

this is strong data manypulation

strong?

yes imagine 4ko to 8ko with only to little image what could it be 
with 30 images ?

try it, it don't change - i tried with 30 400x400 sized pictures!
just 16k

the image isn't evaluated in "face/data: either tail? ..." it's just 
a pointer affectation

try to remove "show face" -> no memory leak

sorry-retried it - it's not 'show - events maybe - or  something 
else

k

I remove the show ace and I still have memoru leak

(sorry my error - the window didn't has the focus - so i interpreted 
wrongly)

vincent in private we continue this debat lol ;)

I'm keen to see your findings / conclusion on this one. Nailing "memory 
leaks" early in the design is a high priority.


If the "problem" is with 'show then we can always do something simple 
like:

	show*: :show
	show: func [face [object! block!]][show* face recycle]

Not sure about the performance hit though ...

Anyone know where I can get a good free set of XP (or XP-like) toolbar 
icons (22x22) that I can distribute without issue? (I'll acknowledge 
the author(s) in the source and documentation).

Ask Chris ...