World: r3wp

make-doc, yes, that reminds of makedoc3 I'm still waitnig for ;)

(ah, emotions are slowly comming back to my writing so I should better 
shut up ;)

my message from this morning: "(personally i want it to be dynamic. 
like adding people when i have some vid stuff to show.)"

no code first - i don't design from thin air. i need to write code 
to design. i don't care if it's thrown away, i do that all the time.

there's no way i will be able to write any design doc other than 
the one i've written more than one year ago without writing some 
prototypes.

Brain - my view is based upon endless RT's promisses and non delivered 
things, concepts, which are published, and then silently disapper, 
etc., sadly ... The basic road block being a communication.

Others mileage may vary, but I learn a lot more from code than from 
docs... within

balance of course...in particular a "get started doc" is critical. 
 After that realtime
exploring is the way to learn.

And I would like to warn us, upon my experience of team leadership 
here, that if some formal rules are not set for the future, we will 
not handle the situation.

Pekr: well, actually, Having Gabriele working on it rather than Carl 
is good news to me.

it means more communication... look, Gabriele actually is speaking 
with us... and IS here every day.

Yep.  And a formalized group may address some of that...may be not, 
but I think it'll be
worth the effort.

you see, I'm not against this whole thing .

the power

 is still way too centralised. New ppl will come. And that is why 
 I asked Carl even about concepts like DevBase, DocBase, BugBase, 
 localisations, communication principles with userbase, etc. - but 
 that is different topic ....

Pekr;  Yep RT has promised things...but (and this is where being 
out of the computer

biz for seven years may be of benefit to me) it seems things are 
really starting to
accelerate.

petr, can you elaborate more on abstraction? was my proposal too 
abstract or not abstract enough?

the direction of abstraction ... I was not sure about isolation of 
data from visual representation ...

just one last quick note: I think that having a look at MUI will 
be good - MUI resizes buttons automatically to fit the text in, there 
are no absolute coordinates. Someone may think, that absolute coordinates 
are good (bitmap graphic-heavy people), but absolute coordinations 
are PURE EVIL, at least from internalization/Localization POV. And 
if the GUI is not made with internalization in mind from the beginning, 
it's not possible to add it later (if it was, there won't be about 
forty people resing every button in Vista for every language edition 
manually)

Petr, don't forget though, that "decentralized" design is exactly 
what Carl is opposed to.

too much isolation of data or not enough isolation of data?

no, not centralised vs decentralised design, but the whole things. 
I miss division of tasks ...

Gabriele;  I agree.  As an end-user, a single (perhaps extensible) 
vision has always
been far more appealing to me than design by commitee bloat.

Rebolek: i have programmed a MUI like gui engine in AmigaE some 12 
years ago.

too much - well, not too much - just the whole idea - are we sure 
we want to let user choose, in what form he wants data being represented? 
I am not sure it is neede? Would you find it really usefull?

And Pekr;  If the design include points of extensibility, thats where 
"we" get to play.  :)

ok, so it's the same concern Carl has that it would be too complicated.

i can only answer that concern by writing a prototype. there's no 
way a "it won't be complicated" will convince Carl or you :)

Brian - misunderstood :-) decentralisation = decentralisation of 
tasks - someone does design, some group works on docs, some groups 
are rebol evangelists on internet, some group might help new users, 
etc., I don't want to bloat anything ;-)

not sure if complicated, but question to you - would you find the 
practical need to have different representation of data? I mean, 
as an app user?

Gabriele that's good. It's just that this is one thing that is nor 
adressed in current VID, RebGUI etc and it would be really great 
if new VID will have this from the begining. Take it just as a wish 
:)

petr, isn't that exactly what is happening? Carl works on design, 
some group will work on docs (DocBase), other groups will work on 
code (DevBase), other groups can be here helping users as they have 
always done

but you see, Carl has PITS embeded in his mind... the problem is 
that if you want power in a GUI at some point, some things need to 
be more extensive.  which can imply complexity.

Ok.  I'm all for that.  Sign me up for some grunt work...  :)

otherwise, we should just port current vid and add a few things in 
the dialect.

rebolek: i would prefer a simpler, more powerful approach than the 
one used in mui. however, probably mui is easier to understad to 
people (html tables even easier), so we'll need to stick to that.

Gabriele-  no, it is NOT happening. I believe you release R3 sooner 
than we might come familiar with all those needed systems. Has anyone 
discussed, e.g. if/how we allow localisation of docs? Etc.?

IIRC think carl really likes the simplicity and power of GLayout's 
proportional sizing engine.

its a prototype so yess the *code* has some ugly bits... but the 
layout concept is very agile, and makes tidy guis with little effort 
and understanding needed... its acutally much simpler than current 
vVID.

max, that's exactly what i did 12 years ago. no news to me. i wanted 
to try something new but that's not going to work so i won't.

And sorry Pekr;  I get my verbology wrong sometimes...  Wasn't meant 
as a diss.

I actually think, along with this heated debate, things are going 
to accelerate and

we are going to have more chance to get our hands dirty than any 
of us may be able
to handle.  It's going to great.

going to BE great.

Gabriele: I'm not trying to push MUI aprroach somehow, it's just 
that I'd like to see new VID to be localization-friendly

my point earlier was I'd like R3 to have time to actually try out 
different approaches, have them working code, let the community try 
out, maybe even create different propositions and take the time to 
use and have fun.

then the best parts of each idea usually really just pop up as *obvious*.

but having a june 30 date just allow a single track to move along 
so... I understand why/how you are approaching the whole thing... 
and yess I think you are courageous for asking openly here.

you just *knew* what was comming  ;-)

Maxim;  That can be good...but it can also be dangerous.  Everyone 
here is too smart
and has too many good ideas.  May become overwhelming.  :)

max, i hoped to prove carl wrong, but he seems to be right :P

hehe

Gabriele, team work depends on all aspects of the work to be teamed.

And I don't mean too smart in a bad way.  The computer IQ in this 
forum is off the scale

which is why Carl is right.