World: r3wp

I'm hoping for better apply support too - rebcode's apply is so slow 
I found myself inlining functions by hand.

I also wanted support for more datatypes. I was looking at rebcode 
as a compilation target. It never mattered to me how it looked since 
I was only rarely going to write it out - most of my code will be 
generated.

I'm looking forward to the "BRIAN" NEW rebcode. : )

Brian - that sounds cool. Please bug Carl and Gabriele about Rebcode 
improvements ;-)

no need to bug me, i already want all that stuff. i guess it'll be 
3.1 rather than 3.0 though. remember 3.0 is only a couple months 
away...

3.1? sniff :'-(

the new stuff. basic rebcode will probably be in 3.0. but guys, we 
have priorities. you want vid improvements before of rebcode, don't 
you?

:)

Gabriele - NOOOOOOO - no VID improvements ....

I don't believe it can be complete, so let's forget VID, it has so 
many defficiencies, so it should be either completly redesigned (you 
can't easily just to "improve" VID), or forgot ....

we had this discussion during devcon (me, carl, nenad, cyphre, rebolek, 
max, etc.)

but I suspect typical scenario. There is imo no VID+ group active. 
It will be cooked behind the closed door, and then you will complain, 
that I will complain :-)

ah, and what is the result ...

?

my idea was: let's write something from scratch that uses all the 
good ideas from vid, glayout, rebgui, liquid and so on.

carl answer was, we need this RSN... no time for this. (others agreed, 
sort of)

btw - as you are close to RT - what happened (or will happen) to 
rebol's security schema? IIRC Josh was working on some document - 
was it only regarding plug-in, or did it influence also general rebol 
interpreter, rebcode, etc.?

so my answer was, well, let's improve vid, and at the same time develop 
the new system, so that we have vid (with resizing, liquid-alike 
stuff, more styles etc.) for 3.0 (or at worst 3.1) and we can have 
the new system later on.

With RebGUI state, although VID my be more free-form, I refuse to 
even touch the thing, which does not have scrollers with area, list-box 
is not indexed and it hilites two the same values, and tonnes of 
other problems ...

but there was no real agreement about what the new system should 
be. so... well, it's too early to say anything about it now. what 
we now is that we need something like vid for r3 too.

ok - different pov - do you expect current VID scripts to run with 
View 1.3? Will you "emulate" face aproach, etc.?

ah, with View 3.0

probably most will run... but it's hard to say at this point. it 
depends on the amount of time we have. keep in mind reichart is taking 
my and richard's time too.

ah, ok, there is a Reichart to blame. Reichart - where are you?! 
:-)

Gabriele, are you planning to follow up on the design document you 
posted when we talked R3 GUI design?

I wouldn't mind VID for 3.0. All my programs are VID anyway

I have heard Gabriele proposed to use rebservices for the 'feel part, 
which is imo insane idea :-) (would be slow imo :-)

i do plan on that - but only as long as carl agrees to that, and 
i need to show him some prototype to convince him it's not going 
to be too complicated.

what was Carl's reaction to glayout and liquid?

not rebservices directly, but just "messages" for events, so you 
can also send them thru rebservices.

ah, that makes more sense ...

he likes it a lot (liquidgl), but it's too big, so max will need 
to "distill" it a bit :)

that is, my idea (which carl agreed on, and i think others too), 
is that the app does not get a mouse click event, it gets a "button 
pressed" event. (not sure if the explanation is clear)

hmm, maybe we could use kind of devices for that, no? Events could 
be queued etc. :-)

chatting in wrong group once again .... :-)

yep, please move :)

I'm sure I don't want VID improvements before of rebcode.... I want 
CORE with rebcode first... And I really hope that some release  will 
not be postponed just because there is no  new tree-list GUI or something 
else

exactly - Core is the infrastructure - let us play with kernel first 
...

Oldes - but maybe RT has real concern here. You can imagine there 
will be many requests for furhter improvements, bug fixes, etc., 
so that we can "steal" time from RT's resources and hence View could 
get even more postponed ... dunno ...

yes, I know... i'm very patient...

core with rebcode is a different thing from core with all the rebcode 
improvements that have been proposed.

there is so many proposed improvements? I thought that Brian requested 
few opcodes?

.... remembering when rebcode was introduced, Carl seemed to implement 
improvements in light speed :-)

even if there are only a few... it's still some time subtracted from 
other stuff. so i can't promise anything about that, especially since 
i don't know the details of everything.

Carl might be able to give you a much better answer...

Carl would have to visit us here from time to time, to get us a better 
answer :-)

The old versions are still out there, Windows only.
Not true!
rebview1350024 from 16-Oct-2005 is for OSX incl. rebcode.

My guess is, rebview1350042 from 14-Oct-2005 include rebcode too. 
Haven't tried it out though.

It's the first version of rebcode, you'll find in those. A later 
version was released for Windows, yes.

Geomol - does codebase for RPaint still exist? Will you resurrect 
the app once new compositing enigne with R3 is inplace, along with 
rebcode?

Pekr, yes and yes, I plan to complete RPaint, when I can.