World: r3wp

Every time the quality of RebGUI increase. Every new version is a 
must one.  Good job every one ;)

What about a single column text-list? IMO this one is needed too.

could be usefull to make only single column lists, but make them 
share the same scroll

Yes, this would allow to build simple tables that move in sync.

another trick is to focus on the headers, and let the list-part be 
build by the user. where the header keeps some info for the list, 
like the column-width/resizing.

third, keep a user-reference in the row, where user can refer back 
to the real data.

RebGUI is looking nicer with every build.

Could you make the drop-list - with the auto-fill too? even if it's 
not editable.  Would make easier to find a value.

if it's not editable how dare you want to input text ?

Luisc: It's on the ToDo list. From the release notes above:

	Known issues
		...
		- edit-list needs auto-fill logic added

Could you make the drop-list - with the auto-fill too? even if it's 
not editable.  Would make easier to find a value.
 I think he is really talking about drop-list not edit-list ...

Hi. Back after one week spent in Buddhistic ashram :-)

I just tried RebGui 022 and would like to report something: Lists 
- once you open selection menu, you can't close it by clicking outside 
of it. ESC works, which is good, but clicking outside the menu should 
close it imo ...

requestors are nice!

What hits my eye a bit though is LED design - too boxy/narrow in 
comparison to check-boxes, radio-buttons etc. The color is a bit 
obtrusive and maybe not all their area needs to be filled with particular 
color? But that is just very cosmetic detail ...

What bothers me more (although with older View 1.2.46 - the memory 
consumption starts growing, even if I do nothing. Anyone noticed 
anything like that?

the event system does that - after a while, some megs, it should 
be garbage collected

A 'recycle was done by RebGUI in earlier versions (patched 'show 
function)

thanks ...

the problem of a recycle into show is tha it's performance consumer 
...

maybe we need to talk to carl about this point in order for him to 
make a more efficient way to garbage collect ...

and ofcourse conserving a good process speed :)

maybe it could be preferable to desalocate a content automatically 
when the content change ....

but this is an improvement internal to Core functionnalities ;)

when you do a: 123 then a: "fdsbfsdjbh" it would be interresting 
to detect if the a word yet exist and then trash the interger (123) 
content of this word and then allocate to the word a the string! 
new content.. this will be an internal  totally transparent way to 
handle memory allocation /deallocation

and this will influence every var content (I think that's better 
than having memory leak when event are used ....

new GC is inserted into 102 version but I francly don't see any différence 
in tour.r with RebGUI 0.22  we start a 6800 Ko and the memory is 
cleaned when 8500 Ko is reached and cleaned  to 7400 Ko ...

(regarding de/allocation) I don't know if it would change something 
in our case: in /View, event objects are generated by user/system. 
The event object carrying mouse 'move information may not be used, 
but one can only know and discard it at the end of the event processing 
chain (a global event-func or a face feel) - could be tricky to do

new GC: it must be various corrections to crashes and speedups. I 
don't know if anything has changed on conditions for garbage collection 
triggering.

I think the memory leak problem with VID  is closely related with 
way data are alocated in general

for example the mouse pointer event is stored into the same var but 
betwin two allocations you have no memory clear so glob vars are 
the same the content is not the same and the only thing that change 
is the memory adress related to the new data allocated

this make increase the memory use until it reach a certain level 
then it's trash maybe it could be bettre to make on new data allocation 
the systematical deallocation of the previous content instead of 
having them surviving into the memory ...

each event is a new object, you can't reuse the same memory place. 
example:

t: copy [] a: insert-event-func [append t event event]
view layout [button "unview" [unview]]
remove-event-func :a
print length? t

foreach e t [probe e/1]

in this case why the previous obj is not trashed those object have 
a short life time this muts be taked in count I think

In all cases we can solve this by patching the show but this force 
the intensive use a recycle witch was  not designed to do ths ...

Maybe recycle could take an argument, which specifies a word to take 
particular note of.

yes this would be a first step  ;) instead of scanning comparing 
the whole memory

but the point is that we don't know exactly how recycle works

does it scan the entire memory ? does it make the comparaso betwin 
the whole memory content table and the actual rebol word content 
?

If rebol keeps track of all previous existing data doesn't it simpliest 
to trash those datas when a next allocation is done ?

Can we move this discussion to the View or Performance group? ;)

sure :)

Hi Ashley and Shadwolf  sorry if i didn't answer before i was out 
of town ( mother's day =P ) let me explained to you why the auto-fill 
on a drop-list ...

If you have a big drop-list ( non editable ) with 60 salesman ( big 
store ) and you shadwolf because of your name are close to the 50th. 
position the way to select your name frome that drop list would be 
with the mouse

wouldn't be easier if you typed sh on the drop-list to select your 
name instead ?

and no i am not talking about an edit-list. And is not an auto-fill 
per se routine. More like a keystroke capture routine so that it 
would do a search on the list  = )

Luisc: usually, drop-lists don't work well with big lists - it's 
quite hard on long lists to select something without mistakely closing 
the list. A classic text-list is far more suited for anything longer 
than 10 elements. A 60 items drop-list will raise a lot of problems: 
if the widget is too low on screen, most of the choices will be hidden.

Unless your droplist widget adds a scrollbar when there are more 
elements than you specify space in the widget for, like in Windows.