World: r3wp

and if you undo on an arrow draw, you lose the state setting, and 
so everything after that has arrows on it :(

I can catch when you change from arrow to something else... but .. 
if I undo, I can't ...

probably needs some type of stack

It sounds like arrow should not be a tool, rather a mode that affects 
all/most tools.

Hmm.  Perhaps so.

Otherwise I suggest switch arrow on, draw line with arrow head on 
it, switch arrow off.

If it's a mode, then it should be a check-box, not a radio.

I did that before I realised it was a state.

that might work .. undo the arrow immediately after the draw.

Actually, even if it's a mode, you should compose the draw block 
like (very pseudo-code):

 compose [ (either arrow-on? [enable-arrow][])  (draw-cmd-eg.line) 
  (either arrow-on? [disable-arrow][])  ]

Just ideas, I didn't look at the code this time.

That works ... turning off arrow immediately.

now up on rebol.org

what would it take to have text flow automatically around a rectangular 
image in a area field?

There is new release of View - no docs though ...

probably a rebcode update

maybe, but rebcobe binding bug is still not fixed :(((

or rebservices already integrated? looks smaller though ...

can't find string "rebservice" anywhere in system object

we've got draw text which can follow a spline .. so why not have 
text that knows the boundary of an image object ?

I have noticed, that there is new (dunno how long it is in rebol) 
command line parameter, called -v (noviewtop) and I have few comments. 
I am not sure that it was not added in-there because of my Rambo 
ticket, which asked for introduction of no-connect option instead. 
So, the trouble with obtrusive and annoying View desktop trying to 
connect to internet, is still there, and it really puts rebol worth 
sending into trashcan on such affected machine ;-)

Second - why ViewTop? and if ViewTop, why we still call desktop a 
Desktop? That is imo inconsistent ...

so -v might be usefull though, but - please, if we can't do proper 
async, where even system buttons are blocked and you can't even shut-down 
rebol task via ctrl, alt, del, then add noconnect option, please 
....

What does async in such circumstances? rebservices (should) have 
http-async, then it may be solvable easily.

dunno. It does not matter. But it seems rudiculoust to see app blocked 
for 10 - 30 secs, not being able to even shut it down ...

AFAIK os takes that long to report an error. and with sync, rebol 
can do nothing before an os-reply.

don't care ;-)

.... because .... OS does not take so long imo :-)) Isn't it just 
a question to set lower default time-out thant 30 sec, or what was 
the value?

I don't know. Thought i read somewhere something can not be influenced.

IIRC rebol uses 30 secs for timeout ... :

get in make port! http://www.rebol.com'timeout
== 30

WHat does a normal read? also timeout for so long?

imo, with current speed of broadbands, where dial-ups are going away, 
something like 5 secs of timeout could be enough?

trying ...

the trouble is imo with get-net-info - it is so arcane, that it can't 
be true anymore :-) IIRC there is check for old Netscape, parsing 
of prefs.js etc ...., whereas possible mozilla settings are not taken 
care of.

21 secs here for timeout:


start: now/time attempt [read http://www.rebol.com] print now/time 
- start
= 21

And if you change the timeout?

what's wrong with turn off auto-connect in the settings?

New users.

the setting itself is available only after the first timeout, that's 
wrong ;-)

Volker, yes, changing system/standard/port/timout: 5  really seems 
to timeout in 5 secs ....

ok, but you just stated that because almost everyone is on broadband, 
that the timeout doesn't need to be as long. But if everyone is on 
broadband, they should be able to connect :-)

If the band is bound to a proxy, maybe not.

yes, they should, but then rebol's ability to read system proxy settings 
should be fixed - I know what I talk about ;-)

Maybe that 5 sec is worth a rambo-ticket?

I even wrote down the strategy during first plug-in attempt, as it 
had exactly the same problems. But it is imo lost in old World. Imo 
we could try to revise get-net-info instead?

... and yes, lowering the timeout, could make situation more acceptable 
...

5 seconds might not be enough time for the first time user to allow 
the user to respond to a software firewall (to add rebol to the allow 
list) and still get a connection.

Maybe a requester. "Testing proxy" and choice for seconds

if async oes not fix it.

hmm, then get-net-info should be revised ...