World: r3wp

Rebolek quite summed it nicely - we simply fear, we will not be able 
to comment soon enough, before the design is released.

And why? Because it already happened in the past.

can i do anything about that fear?

if I may suggest something you (and Carl) should write a document 
about new VID internals (how it will work, what it is going to support) 
- no code required in this phase. Then please release this document 
and have others to comment it. Then rewrite the document according 
to proposals you like and then someone should start to code, be it 
you, Carl, some RT outsider....whoever best fits the task.

I'm just afraid that "programming in the large" will not apply to 
the GUI.

Yes - write some proposal. Don't even show it to me, Rebolek, just 
few selected ones - Ashley, Anton, Maxim, Henrik ... fair enough.

FYI;  The informal Bob's Rules of Order time limit runs out on the 
REBOL User group

proposal tomorrow.  I think there is some consensus, and reading 
this it really looks

like a formalized Executive Summary would be beneficial to everybody. 
 Even if it

never gets read at RT, it'll let the community vent steam and brainstorm. 
 Expect 

an Agenda for the formation of a formal group on Saturday.  First 
meeting here on

Sunday-Monday-Tuesday.  I've tagged Bob's rule at 72 hours of 'floor' 
time,
(unless voted on and changed) after the organization forms.

because it's hard to harvest some comments to new VID when there's 
nothing on the table

let them shortly review and discuss general direction ... once agreed 
upon, close the door with Cyphre, buy lots of pizza and don't come 
out, unless you are ready with first prototype :-)

how is this different from what i said in the beginning - i want 
people to look at my vid as soon as i have something to show and 
get their comments.

Gabriele if that is what you said in the beggining than sorry, but 
it was somewhat lost in the noise

than everything's OK, just tell us when you're going to publish this 
proposal ;)

Gabriele = my VID = actual implementation already, no? Because - 
I looked at your former proposal/doc, and I am not sure I agreed 
to abstraction which was put into it ...

no code first, please, just some make-doc notes ...

because - if you decide to change some principle, it might mean to 
throw away some part of the code.

I'm going so side with Gabriele on this one.  Partly because it seems 
he is being

ganged up on at the moment, and I think it is the best interest of 
the common good to

let stuff roll and then discuss, rather than discuss and let roll. 
 (Given some trust of
good thorough work of course...)

It seems I may be at odds with Pekr's view.

I really take Henrik, Ashley, Anton and Max as ppl, who use rebol 
in various areas of real-life apps, or at least have deep enough 
knowledge of VID internals to help you ...

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.