World: r3wp

Cyphre, Henrik, Ladislav and I are going to pic up the current VID34 
code and drive it forward. Our goal is to get it into a shape that 
it can be used to build apps.


We will try to sync with Carl about our steps to avoid that we fork 
away. Overall we want to solve the current stuck situation and move 
forward.


Our goal is to make VID34 useable for big apps. Focus is neither 
minimalistic nor "can be used by a child". This will be for the big 
boys. But still simpe to use and providing a bunch of features you 
need to make enterprise applications.

All this is done in the context of one of my companies: www.rm-asset.com 
that will sponsor the development.

good deal ... and why not a fork ? i mean VID3.4 can be used as module 
or side library

This is the software development company doing the commercial apps 
for other companies. Our goal is to create a professional framework 
we will use for all our developments.

I pretty like the idea of a more reactive VID made and maintained 
by the community   something with really open source that I could 
acces any time solve the bugs that's slows my  dev and share the 
patch i made. I'm better at finding solutions to existing problems 
than inventing new problems

@Shadwolf: If Carl doesn't agree with what we do or wants to position 
VID34 different than it will be a fork. Overall I still think we 
should avoid creating to much GUI forks and fragment our little community 
forces but instead pool forces to faster move forward.

But our mission is clear: We will get a R3-GUI up & working that 
will hold for big apps.

Robert i think 2 years ago the reply from carl was christal clear 
VID3.4 is not what he wanted  drop it he would do VID alone when 
he get the time and in the mean time 2 years 24  month  we lost  
an opportunity to motivate ourselves to get VID 3.4  tuned up

and even VID 3.4 can be a school for people to get a first concrete 
access to what is in rebol and how things are done in it

how do you want people contribute with quality when they don't have 
a sand bow to shape their abilities ?

That's why we now drive things forward. And we will document it, 
so it's as simple as possible to let other contribute, fix things 
etc.

anyway it have to be easy ... the easier it is the faster you will 
be able to port it and / or solve emerging problems

and simple as rebol shown us those last 10 years doesn't means cheap 
capabilities

We'd like to avoid forks, so I think we should break steps up in 
a concrete way, so Carl can chime in on what he likes, doesn't like 
and what he can improve, swap out easily, etc. Right now, I've been 
working on face traversal and am now working on tags.

I'm unclear here .. which one are you now working on ?  Carl's code 
or Gabriele's code ?

Carl's code.

Carl seems to have some specific stuff in mind for vid direction 
but he is just not going to get to it anytime soon...I do not see 
a prob with you guys coming up with an alternate vid (rebgui for 
r3) in the mean time...each gui may be addressing different needs 
anyway. Carl's VID, when ready, can become the defacto and distributed 
with R3 but in the mean time we can use the alternate to push R use 
forward.

right now... what we are waiting to get R3 VID going as an open, 
steady, team effort, really is the next host release with VID implemented 
as an extension.

IMHO, Henrik has stepped up as project manager for R3VID.  Cyphre 
is still interested in helping out on the low-level AGG AFAIK.   
Others, like me, will definitely chime-in when it starts being more 
organized, if only to implement Styles, themes and stuff like that.


But we need the next host released... and AFAICT, that is one of 
the main projects of Carl right now.  At least, I hope it is.

I might also work on some low-level stuff, which is what I'm more 
interested in helping on right now.

even for the OpenGL implementation, the next host will make my job 
easier AFAIK.

Tags are now implemented. Now it's a matter of using them.

Henrik - what is the plan to get Carl's opinion on some of his known 
plans, e.g. layers. Shouldn't you know, how were those supposed to 
work, etc., before you do any other design decisions?

It would be preferable, yes. It depends how we can push it around, 
as I'm not sure Carl will want to go into GUI work now.

well, such claims sound very strange. One of the reasons why Carl 
forked GUI was, that he did not agree to some concepts. So it really 
surprises me, that you plan to continue to work on VID, without any 
coordination ... that once again asks for later fork. I think that 
for Carl to explain/document his ideas would not mean more than few 
hours of his work ...

if you do only preparation/documentation work right now, everything 
is ok then ...

The way we implement things is so they can rather quickly be pulled 
out again, if we have to and revert to the original VID3.4, and the 
implementations will be documented clearly.

Since there is a business decision on the line, we can't afford to 
wait with implementation, even if Carl doesn't like it, but we still 
want to stay friends with him. :-)

so we really are talking fork here :-) Well, I will be glad for any 
GUI for R3, that is a fact. It is just that I thought managing Carl 
for some 1-2 hours chat on some isolated group here would not hurt, 
and you would simply know, what Carl's plan is. I can understand 
business driven decisions ... but anyway ...

I prefer to have our changes gradually being applied to the official 
VID3.4, rather than just declare it a fork immediately. But we'll 
see.

Any working GUI is preferable to an official broken one.

Even if an official GUI is released tomorrow it will not be all things 
to all people and some will develop other gui's (rebgui, maxim's 
glass etc) why not start now as opposed to later. It need not be 
considered a folk of the offical vid...just an alternative choice. 
the official when released will be adopted if it works well enough 
so you won't be stepping on carl's toes.

folk>fork

Guys, remember that Carl WANTS help?  that means accepting ideas. 
 especially from like-minded people.

AFAIK, Henrik is closest to the source as to how Carl wants VID to 
evolve.  So if you (Henrik) want to put time and effort while the 
next host gets released, I say GO!  


Its time this community stops asking "what does Carl want" all the 
time.  He wants REBOL to be used.  he wants his last 15 years of 
life to mean something to more than himself.


Everything going into R3 is a direct response to what WE have been 
asking for the last decade.  He wants R3 to be what WE need, within 
a few guidelines we all agree to in the first place.


He wants REBOL to grow, and like a child that has grown... Some parts 
of REBOL will grow without him, others will grow with his counsel.

We aren't followers of a sect, waiting for praise from the prophet.


The more we take up projects and move them forwards without his daily 
intervention, the more the overall will be coordinated... 
right now, Carl is still too close to the code IMHO.  


which is why we don't have feedback on some of the projects we start 
work on (like schemes, for example).

The fact that brian has completely taken over parts of the development 
of R3, should be a clue, that there are other areas where this is 
possible.


This is all just my two cents, but in the last year that I have been 
chatting with Carl and some of the people which have "taken responsibility" 
for some stuff in R3, the more Its obvious to me that Carl just wants 
the community to do more... to take up more responsibility.

You got it right.

BTW, the GUI project will be coming back to life soon... and I'll 
only be one of several people working on it.

' :-/   
<sheesh> didn't know you where on line hehehe.

I'm really glad you're posting it. You need a blog.

I really like this line: "he wants his last 15 years of life to mean 
something to more than himself"

I think of that every day.

:-)

you should look at the REBOL3 /library group... quickly... give a 
bit of feedback on a proposed API I will start work on shortly.

Begun detailing the implementations here:

http://rebol.net/wiki/R3_GUI_Implementation

why is it that we can't use reflection functions on GOBs?

Carl why 15  and not 30 ?

Henrik, Some thoughts about the default STATES in faces.



DISABLED --> (the face is removed from its container or not constructed)

INACTIVE  --> (not reacting  to any events or actor, but still here 
and showed)

READONLY --> (reacting to some events (TAB, CTRL+C ...) but not modifiable)

HIDDEN --> (not showed but still in its container and can react (keep 
its place (spaced) on the screen))

hmm, yes, those are possible

notice that we should be able to combinate some of them together.
INACTIVE+READONLY
INACTIVE+HIDDEN

forget INACTIVE+READONLY

READONLY could be for information faces, which aren't INACTIVE.