World: r3wp

yes its in rambo... I'll be sure to nag Carl about it when the alpha's 
start rolling out ;-)

They asked for our favourite bugs recently so now's a good time - 
hopefully they're still in bug-fixing mode.

Hi, it seems quite a while ago that i did something in /view so i 
lost some knowledge about it. Can anybody help me out with how to 
change the color of a button when i press it?

specify two colors attributes, same thing for text 
 ex: showing button and toggle styles:


view layout [button "ok" red blue toggle "press" "me" black green]

and what if the color should only change when a condition is true??? 
is there something like button/color??

Thorsten, yes, but button/colors are used for that. Try this:

>> l: layout [b: btn "Red/Blue" red blue btn "Make Yellow" [b/colors: 
[yellow blue] show b]]
You can view it by:
>> view l
and look at the button with:
>> ? b

You can also see the colors block with:
>> ? b/colors

Hi Geomol,  this seems to me what i was looking for. Will try it 
out asap. Thanks

Anyone know what the to-vector function is for in the new view 2.7 
build for windows?

There's a what ?

>> to-vector "1"

crashes

TO-VECTOR doesn't look implemented. There are other bugs with it:
>> v: to-vector 1
== 1
>> v/1
== #"^]"
>> v/2
== none
>> v: to-vector 2.2
== 2.2
>> v/1
== #"^!"

If you want to see the new crash error message window, type this:
to-vector "x"

(should move bug discussions to RAMBO group)

vector! is a DT that was being implemented to represent real arrays 
(i.e. so that 10 integers do not take 160 bytes, but just 40). it 
would mainly be useful for rebcode, but there are many other cases 
when it is useful.

not sure if it will happen for r2 though.

gabriele, sounds very interesting. I was although hoping a bit for 
a system to use arithmetics on blocks of numbers.

Thanks Gabriele

i guess arithmetics would be possible on vector!. (but then, what 
kind of product? :)

has there been any talks about complex numbers? electronics guys 
love those :-)

How do I resize a text-list horizontally?
I tried this code
view layout/size [
    tl: text-list data ["A" "B" "C"]
    across

    btn "+" [tl/size: tl/size + 10x0 tl/sld/offset: tl/sld/offset + 10x0 
    show tl]

    btn "-" [tl/size: tl/size - 10x0 tl/sld/offset: tl/sld/offset - 10x0 
    show tl]
] 300x300
which works if the text-list is made smaller.
But if it's made bigger I get artifacts.
What else needs to be set in the text list to make it work?

; how about using /resize, or stealing code from it?

view layout/size [
    tl: text-list data ["A" "B" "C"]
    across
    btn "+" [tl/resize/x: tl/size/x + 10  show tl]
    btn "-" [tl/resize/x: tl/size/x - 10  show tl]
] 300x300

Excllent ... thanks gregg

hum... anyone have success using the highlight-start/end values to 
setup view selection highlight in fields?

doh... sorry... copy/paste error in my code.  selection is working 
fine.  thx

Hi all,


what might be the best way to have a window with a process running

in the background, checking something and if a change occurs, the 
window ist
updated???


I made a GUI and function for the check. Checking and updating the

window via button is working fine. Now i thought about implementing 
a

process with a forever loop and wanted to start it, when the window
opens or at some time before.

First, i cannot find an 'open event. What can i use instead?
Second, is the forever loop the right way to make the process??

Third, is the event the right way to start the process automatically???

Fourth, how can the loop be stopped without closing the window (button???)

Can anybody help me out?

Something like this might work for you.

view/new layout [
	button "start work" [work-to-do?: true]
]

do-work: func [][
	; <- do a chunk of the work here
	work-to-do?: is-there-more-work?
]

forever [
	if work-to-do? [do-work]
	wait [0.02]
]

I am using another way for a file search application. Ask me if the 
above is not sufficient.

for an onOpen event, you can just enclose it inside a 'do block in 
the layout.

view layout [  .. do [ ] ]

Hi Anton, Graham, thanks for your suggestions. I think i will try 
parts of both approaches.

standard text in REBOL is rather ugly.  What are some of the methods 
that some of you are using to improve your interfaces or make better 
text?

I'm just going with the ugly defaults most of the time. :)

Open MS Word (or equivalent) and look for nice fonts   =^_-=

I need some tips on "How to reduce memory" when using 'make face... 
my current application is eating 13 MB of memory with 90 faces...I 
have 80 faces that do actualy the same.. And is it standard that 
view eats this much memory? I compaired it with a using layout but 
the memory is not much different..

Mmmm i checked with some other appilcations and it all seems to eat 
this much .... Still some memory reducing hints are welcome...

view always eats a lot of memory.

AFAICT, basically all the bitmaps residing in main ram add up pretty 
quicky... just the main pane of a large window will eat up more ram 
than you'd first expect (800x600x4 = 2MB)  on top of view itself 
taking 8MB.  thats 10MB to start, but each face takes up its own 
bitmap space.  stylesheets also take up a lot of space, of if you 
use any style or stylize words in your app that also will nudge some 
space.

mmmm.... yes I thought by switching from VID to my own faces I could 
reduce memory, but thats not true I discovered. Im currently in the 
range of using 17 MB memory , thats very close to JAVA memory consumption... 
Why must a GUI must eat this amount of memory? .. As 'view communicates 
on top of the OS layer I would not expect it to eat this much.. The 
executable might be 850 K but executing explodes it... even 'altme 
eats "more" then Firefox ... Oke 'view is very flexible..very flexible 
compared to other GUI's..still with all the nested pointers etc must 
it eat this much?...mmmmm..... That brings be actualy to some other 
facts questions... What commands/functions must people NOT use when 
using faces? I mean regarding speed.. I discovered that 'draw functions 
slow down view and also a 'foreach loop stucks waking trough 80 faces... 
Would be nice if Carl could open-up a little bit more in 'tuning 
faces...;-)

17 MB is very low for a rebol script, I think. :-) I've seen them 
eat up towards 1 GB of memory. View does eat a lot. Why I don't know, 
but it must have something to do with buffered uncompressed bitmaps.

it is related mainly to non oop design. IIRc R3 will carry inheritance 
(classes). It may be related to each function in object to be simply 
once and once again with each new instance of face. According to 
Cyphre memory savings could be 1/3 to 2/3 of memory in some cases. 
But better ask him ...

not sure about that Pekr.

classes wont solve the cached bitmap issues.  which is what really 
consumes memory IMHO.

newer engine will use only AGG which will compute more stuff on the 
fly... and thus would be more memory efficient... but at what cost 
in speed.  I hope that speed will not suffer, when compared to an 
app which does not use AGG.

is this a bug? 
** Script Error: Invalid argument: random
** Where: to-image
** Near: to image! :value
>> q

*** glibc detected *** double free or corruption (out): 0x08540c30 
***

                                                                      Aborted

created when doing -> iface/effect: compose [ draw [pen black fill-pen 
random 100.100.100 box 10 10 8]] , I know it should be (random 100.100.100).. 
still a nice error NOT catched !

posted in rambo...

We are trying to lower memory footprint of view in R3 as much as 
possible. The new GOBs should be much smaller in size than current 
faces. Also the new compositing should eat less memory trying to 
avoid temporary buffers whenever possible. I believe R3/View will 
be much efficient in that way as everyone here wants Rebol running 
on his own Phone/PDA isn't it? ;)

:-)