World: r3wp

Which version is it most similar to ?

I believe Gabriele's.

in rambo it sais part of 2.7 release... I guess its Carl's reduced 
version?

anton, do you remember this one:


view layout [text "Push and drag out. The highlight should go away 
when the mouse exits, but it doesn't." tog "Test"]


I remember you talking about that you made a fix for that, which 
didn't work. Do you think we could make a proper fix for View 2.7.x?

max, since it is native, probably none of them. it has the same interface 
of the proposals, which is what counts.

Yeah and now that it is native it is faster than select for single 
selections.

Henrik, here's a quick 5-minute patch (not well tested).

body: second get in svv/vid-styles/tog/feel 'engage 
insert body bind bind [
	if action = 'away [over face false event]
	if action = 'over [over face true event]
] svv/vid-styles/tog/feel body/4
view center-face layout [tog "hello"]

Essentially, the ENGAGE 'away and 'over events are called when dragging 
off, and back onto, the face, and I redirect the events to the existing 
OVER function, which normally doesn't get events with the mouse pressed.

I don't really like that hover state anyway. In my style-gallery.r 
I'm aiming to use a similar highlight to indicate the focused state 
of the btn or tog.

Max, about UNC paths: the only problem with REBOL's way of (not) 
supporting them is when your hostname is only one letter long. do 
you see any other problems?

How does Carl decide what goes native and what does?

Why switch, and not case ?

append got native too :-) well, imo if you use something often, in 
mezzanine level, then it could be brought to native level? Imo it 
could be even profilet, to know if the speed gain is there or not, 
no?

I don't think it's very wise to implement 'switch native in 2.7 when 
it can broke old code. Save it for 3.0, why not, but why breaking 
the compatibility, when it's not necesary?

perhaps it's a sneaky way of testing R3 code? :-)

you can always redefine it back again.

I am with Rebolek here - 2.x family should stay as separate branch, 
usable in what it offers, no new experiments.

but maybe compatibility issue here is not a problem?

Pekr: older switch evaluates values , newer does not 
>>b: [print "!"] switch 1 [1 b]
prints "!" in older versions, returns none! in 2.7.2

that is rather big change in behavior, no? But it was probably discussed 
here enough, so that 2.7.2 is kind of consensus of developers opinion?

yes it was discussed,

anton, should we rambo it as it is?

anton, (about your patch)

anton, I tried TOGs, BTNs and overlapping TOGs and they all work 
without this problem now. looks OK to me.

Rebolek you make a good point about the switch.  Maybe we should 
modify it so that it can find block! or type? block!  - of course 
it is native right now so I have no idea what that means for the 
code.

Which I don't know if that is very desirable either as some may want 
just the block returned and not evaluate as it would now if in your 
example the b were in build in the case such as [1 [b]]         But 
in any event you can get the effect you want with the current switch 
by doing this:  do switch 1 [1 [b]]

Henrik, no, I'll clean it up first. I just thought you might have 
needed it for something. It's in my editor so I ought not to forget 
about it. :)

anton, ok. it would just be very nice to get this fixed properly. 
I've had complaints over this a few times now.

Ok, so it's not just a frivolous claim :) Don't worry, I won't forget.

WTF new switch doesn' evaluate?  that was the point of the previous 
switch.  none of my last 5 years of code will now work.

Example ?

what's the point of changing switch in 2.7?

To make it better ?

at what cost?

This works for me:
>> switch 1 [1 [print "hello"]]
hello

give me a minute... I'll do a real test.

ok I just looked at the above example and yes it makes sense now... 
 I thought it didn't evaluate the content of the block.

so since it does evaluate, yes my code seems to work pretty well 
under 2.7 GLayout presents no artifacts, and liquid will run a little 
faster with newer switch.

Graham, CASE has always been a native. SWITCH needs to be native 
for the BREAK problem I mentioned (otherwise /ALL makes the function 
rather inefficient)

Rebolek: if it really breaks important code, we will revert it back. 
The request for changes to SWITCH was in RAMBO.

why did changing the executable rebol.exe to v2.7 force me to go 
throught setup of user again?

especially since it didn't even change the content of the user.r 
file... but now it accepts it?

Henrik, I published the TOG bug to RAMBO. (It didn't really need 
much cleaning. I just checked that the TOG feel was used only by 
TOG.)

wonderful! thanks :-)

Gabriele: OK, that's reasonable

I have a slightly modified help, that does not evaluate functions 
in objects and ports and that also dumps ports like objects.
>> a: open http://www.rebol.com
connecting to: www.rebol.com
>> help a
A is a port of value:
   scheme          word!     HTTP
   host            string!   "www.rebol.com"
   port-id         integer!  80
   user            none!     none
   pass            none!     none
   target          none!     none
   path            none!     none
   proxy           object!   [host port-id user pass type bypass]
   access          none!     none
   allow           none!     none
   buffer-size     none!     none
   limit           none!     none

   handler         object!   [port-flags open-check close-check write-check 
   ini...
   status          word!     file
   size            integer!  0
   date            date!     6-Nov-2006/21:26:44
   url             string!   "http://www.rebol.com/"

   sub-port        port!     make port! [ scheme: 'tcp host: "www.rebol.com" 
   po...
   locals          object!   [list headers querying]

   state           object!   [flags misc tail num with custom index 
   func fpos i...
   timeout         integer!  30
   local-ip        none!     none
   local-service   none!     none
   remote-service  none!     none
   last-remote-service none! none
   direction       none!     none
   key             none!     none
   strength        none!     none
   algorithm       none!     none
   block-chaining  none!     none
   init-vector     none!     none
   padding         none!     none
   async-modes     none!     none
   remote-ip       none!     none
   local-port      none!     none
   remote-port     none!     none
   backlog         none!     none
   device          none!     none
   speed           none!     none
   data-bits       none!     none
   parity          none!     none
   stop-bits       none!     none
   rts-cts         logic!    true
   user-data       none!     none
   awake           none!     none

Is there interest in including in the new release?

help/secure a/handler/set-modes
    there is a function inside an object or port
USAGE:
    A/HANDLER/SET-MODES port modes

DESCRIPTION:
    (undocumented)
     A/HANDLER/SET-MODES is a function value.

ARGUMENTS:
     port -- An open port spec (Type: any)
     modes -- A mode block (Type: any)

yes... please send this to Carl

very cool!