World: r3wp

... while Cyphre demo, using the same principle, nearly stops .... 
strange ...

no, that's not the same principle, in Cyphre demo I used "engage: 
func [f a e][switch a [time [something]]]....." so it renders ONLY 
when time-event comes, in Rebcircle is "engage: func [f a e][something]...." 
so new image is rendered on every event.

thanks for explanation. I tried to add rate field, but it changed 
nothing ...

there's "to image!" and it's 600x600 pixels so I think it's REBOL 
redraw speed limitation...

Pekr: for different bookmark icon (left bar in desktop), there is 
a "Reset bookmark" script in the Rebol.com/tools folder. See Carl 
advice in the note of this release http://www.rebol.net/notes/rv13-changes.html#section-3

Now that we have 1.3 - any idea on when we get the SDK and Command 
builds?

Soon.

I wonder if IOS will be regenerated for customers too?

Soon again.

OS X!!

cool! I was afraid I will have to use old knowledge for IOS .....

New Qt - the stole our originally planned design for buttons - http://qt4.digitalfanatics.org/articles/images/rc1/qtrc-3.png

the ones made by Chris were really nice (nicer than current XPish 
ones)

http://qt4.digitalfanatics.org/articles/rc1.html

AGG based app - nice :-) http://www.epsitec.ch/cresus/documents/base-f.php

Including the interface?

I was wondering about that color palette in the right lower corner. 
That would be pretty easy to do in Rebol now instead of this primitive 
RGB slider thing, wouldn't it?

Back in the pre 1.3 beta, we have got async kernel inside REBOL for 
a while. I would like to ask, if it solved open/skip, open/seek features, 
so that projects like RebDB could proceed? Thanks ....

If I am correct open/skip was solved for 1.3

But I will test this first to be sure.

petr: the /seek refinement requires the new ports of the /async kernel, 
so it wasn't possible to port it back to the old kernel easily.

I know Gabriele - my question was, if async kernel allowed open/seek 
already?

is it possible to have a transparent backdrop in a pane? I'm creating 
a box with some interactive elements in its pane, and I want to see 
what's under the box

face/color: none

none mean transparent for View

it works! thank you :-)

petr: yes, it does. a /seek port operates differently from a /direct 
port. you can try it out on any beta with the async core (i.e. view 
1.2.57)

I notice the new view 1.3 request function now allows the keyboard 
to select an answer.  So, for an alert, a space bar is enough.
how can I get the same functionality with the sdk?

Another easy question, I have a login screen that starts off with

view center-face loginscreen


How do I make it so that the userid field has focus?  At present 
I have to use the mouse to activate the userid field before I can 
type.

f: field
do [focus f]

Thanks.

REQUEST is a mezzanine, so you can SOURCE it and patch it into your 
code.

Was just exploring the REBOL/Desktop and ran into a summary document 
of changes for 1.3.  Don't recall seeing this referenced from other 
sources... http://www.rebol.com/docs/changes-view.html

Of note,  section 2.6 Revised Image Datatype.... http://www.rebol.com/docs/image.html

Gregg, that was the first thing I tried.

I thought I'd ask here in case someone knew before I delved further 
into it.

Thanks Brock, I missed than one. ;)

Anyone know if there is any updates to the new /view such that we 
can activate a button and run a forever loop and still not inhibit 
view events? I don't want to have to use a wait command if I can 
help it.

I can't think of anything, but would wait really be that much of 
a hinderance?  Especially since even wait .0001 works.

Now that View 1.3 is out, does anyone know what the roadmap is ? 
 I would have thought it would be easiest to first release the SDK, 
then LNS, then IOS which may rely on LNS, and then OSX View?  Anyone 
got a better path?

Does anyone knows what the new build http://www.rebol.net/builds/031/rebview1300031a.exe
is?

The following used to work with View 1.2:


 view a: layout [btn 200x200 [view/new/options layout [btn 100x100] 
 reduce ['parent a]]]

but no longer works under 1.3. A bug?

What do you see that's different?

Click button to open 2nd window then click somewhere on the first 
window. With 1.2 the 2nd window correctly stays in the foreground, 
with 1.3 the first window comes to the foreground.

the betas act like 1.3

Looks like the change in behaviour occurred about April 2004

1.2.40.3.1 works as previous 1.2 versions, and 1.2.46.3.1 has the 
current behaviour.

Related to this, alerts used to remain at the front, and now they 
can be hidden by the parent window.

ashley: i think it's a bug. not sure if it's in rambo though.

1.3.0a is a test release. fixes a number of bugs (one important security 
bug in particular). if no new bugs are found there, it will be released 
as 1.3.1.