World: r3wp

You'd then need to somehow run both scripts under separate versions 
of View.exe, and have the interacting in the way they did under a 
single image. 

Perhaps by reengineering  the components talk across third-party 
 port.
Could be tricky!

It's a lot easier for me - I almost never do GUI code with REBOL.

No dis on REBOL - it's just rare that I need to do GUIs at all. No 
interface is easier to use than no interface.

I don't plan to mix R2 and R3 projects. I do have prototypes of things 
written in R2 that will be rewritten for R3.

It will be interesting to see how much compatibility can be achieved, 
if anyone bothers. I think all those fundamental changes will make 
it hard to do. I'm not expecting to be able to stay backwards compatible, 
either.

I think most of my scripts will be mostly compatible. A lot of current 
REBOL code would still run on R1, and that was based on a different 
execution model. Internal changes don't have to mean surface changes 
- the dialects we write in are just skins.

I live mostly in View/VID land..

I decided not to use anything of VID for elixir and instead base 
the whole architecture on liquids.

that allows me to replace the underlying engine at will, with no 
effect on the top level view of the engine.

you see only simple little nodes and have pretty much no clue what 
changing the cursor node of a field will have as effect.

you only know that the cursor will have (possibly) moved by one.. 
but it might actually refuse to advance if your at the end :-)  so 
you cannot break the cursor.

the other pov of this is that the underlying engine does not have 
to be aware why its changing or where that occured... it only knows 
that the cursor really DID change. so it has to reflect itself.

so for elixir, I am thinking of building an OpenGL interface AND 
an AGG view based one using the same software. in fact, we could 
even have two simultaneous symmetric windows running and 0% code 
to add in the software :-)

(one in AGG and one in OpenGL, to compare them)

that is in R3.

part of what I am hoping will be possible anyways.

I've been interested in your Liquid developments. Can it handle non-graphical 
data flow?

liquid is not graphical.   elixir is an attempt at adding a high-level 
editor to liquid, but its actually adding some limitations to what 
can be done with nodes, in order to add structure and reloadability.

but in reality, elixir is not really a *liquid* graph editor.  its 
a graph editor which *USES* liquid.

Can you map nodes to physical world objects?

hum... move to !liquid group?

I don't like how RT will cook new VID behind close doors, period.

That was the whole RAMBO group chat made short :-) Now the longer 
version ....

Gabriele - I EXACTLY expected, you will mention 1.3 open project. 
And I can tell you, why it particularly failed. Not that group could 
not come to some consensus, but also because of Carl himself. Because 
- Carl disappeared from IOS for nearly 3 months, and it was frustrating 
... no reactions to private messages etc. That is not how things 
should work.

And hence - I will never take ANY position, if things are not outlined 
the way I need them to be ... one of the most important thing is 
- communication channel.

Pekr;  The User Group will follow Bob's Rules.  The name is Item 
1 on the agenda.

Open for debate and then (a possibly unfortunate side effect of democracy) 
the vote

of the assembly is the final word.  I'm suggesting [RIG], but lots 
of names will hit the 
floor before the vote.  :)

But - 1.3 project was about concrete implementation ... we wer loosing 
time with things like arguing over button's border thickness etc., 
not starting with bigger picture. But - for new View, there was promissed 
to be SMALL group (so small, that it fits Carl's idea of closed team 
working on new stuff), which will create bigger picture.

but what I can see is, that you have your own ideas of how to cook 
new VID, and I suspect you will do it, propose it, and let us stay 
in the strange position of "take it, or go away".

I repeatedly asked here, if such group works in other altme Worlds, 
etc., and was assured, that once there is a time, it will be formed. 
And I could also see, that guys as Henrik, Anton, would very much 
appreciate being in such group.

As for me, I don't need to, as far as Henrik assured me, that fundamental 
UI things like visual focus representation, proper tabbing, accelerator 
keys, etc., are being cared for ....

btiffin - does it need to be three letter acronym? :-) and btw - 
we should also follow the praxe, which means - maybe such a thing 
needs some spontaneous way to form itself. Currently we are few, 
and we kind of for user group here on altme, working closer together. 
I will reread your post towards the topic, to find out what is the 
purpose of the initiative ...

Nope on the TLA.  R-Space will work.  It'll be a free vote.  But 
it'll have to formal for 
authority

. I'll look into praxe.  Bob's Rules are also on the agenda.  A 100 
year old

set of rules will need to be updated for the Internet, global nature 
of the debates that
will ensue.

what is Bob's Rules? :-)

ok, post me privately some links etc., so I could look at some things 
at the end of the weekend

Sorry, Bob's rules are my take on Robert's Rules of Order.  Links 
coming...

Petr, Carl does not believe in design by committee. (neither do I, 
actually). So a design group for VID won't happen. But, this does 
not mean that feedback is ignored, or that you just take it or go 
away.

about 1.3 project - exactly, so why do the same thing? you can say 
it was Carl's fault, Carl can say it was the community's fault, but 
the result is that the project did not end up in a view 1.3 release.

do we want to end up without a vid 3 release? i don't think so, so 
Carl's fault or not, we just make it happen his way.

RIG - how about REB? Rebol excited/extending/ebetterword buddies?^^

R-Types

Gabriele - sorry, but it seems to me, that your pov is misleading, 
because you try to base it on incorrect presumption. There were some 
rules set. The rules were - Carl decides, I coordinate, write down. 
Sorry, but if someone disappears for 2 - 3 months, then morale of 
group can't be kept high. I am not blaming Carl for anything here, 
that was not my point, but I have to point to the reason of failure 
...

in fact, "design by steering commitee" is kind of broken record from 
RT's side. It would be better to admit, that someone is not used 
to work in real team. That is still fact, but it should be admited, 
or false presumptions are accepted then ...

the truth is, that it si you, who started to talk about commiteee. 
And it is not imo fair to this group, because it was RT, who first 
outlined VID 2 group, as closed group of VERY FEW developers. And 
some of us, remembering Henrik, Anton, expressed their will to accept 
such group invitation ...

so, do you call 3 - 5 ppl group to be a commitee? Besides that, the 
intention of the group was planned just to outline what new VID should 
be, actual implementation could be done by even less ppl.

What I actually see is you collecting ideas, e.g. from Maxim, discussing 
some things, but admitting you will choose only some parts of eventual 
data-flow aproach, maybe without understanding whole Maxim's engine 
purpose? I don't really mind new VID being your or Carl's only decision, 
but what I would regard as being fair is - create some document about 
planned architecture, and let it run via 1 or 2 round of comments 
here. Actually, you prepared your original ideas in such form too 
IIRC.

... because, I would not like to see following happen - you design 
some quick solution, which will not cover past VID missing part, 
which will not be easilly addable, and surely you will not feel comfort, 
if ppl will complain. We were there, and the response was - well, 
VID was written in about a week, and why you don't write your own 
one GUI engine upon View?

well, re-reading my posts - it can sound quite assertive, while I 
don't regard it being so. In fact I try to voice my opinion loudly, 
to prevent some past mistakes.

why you don't write your own one GUI engine upon View?

 ... a valid question, considering a "one size fits all" GUI is hard, 
 if not impossible, to do. I think [small] domain-specific GUI's built 
 on View are the way to go.

Ashley, I might know what you mean, but there should be one more 
complete/robust one, which will serve for "general" app development 
- simply put - most common styles behaving in OS compatible way, 
so that developer might feel safe to push rebol based apps around. 
Of course I can imagine specialised dialected UIs for presentations, 
multimedia, etc.

RT outlined VID 2 group - frankly I have never heard of such a thing 
from Carl.