World: r3wp

I will apply for the job from the other side - user.r . I want to 
help that thing organised. If you would ask btiffin, I think that 
he would understand my points. My main barrier is my english. I can 
be present on internet public forums, evangelising rebol, talk to 
ppl, explain, but I can't represent RT ...

yes, please do. there will be a requirement for much more help, once 
R3 goes beta.

and as for VID3 kicking ass - I hope so, as I like my little fights 
with Bobik between VID and PythonCard, so I really hope I have some 
new fresh blood in my veins for my new round of evening tea talks 
;-)

Henrik - I am already selected user.r community representative, well, 
even if only few ppl voted, the thing was kind of strange :-)

indeed it kicks ass. a very small example:

view [progress slider attach]


slider is attached to progress and will adjust it's length automatically.

ok, let's fight a bit :-)

and you get automatic resizing thrown in for free

I am a new programmer - how it connects? I want to have some imagination 
about it. btw - that was the most difficult part of VID vs View. 
At least when I taught Bobik VID. Once you needed to go deeper, non 
skilled View guru would get lost ...

Sounds great

Henrik - I saw some weird arithmetic expressions for attach. Just 
one question - does it allow named variables instead of integers?

there's a lot more interconnection between words in VID now.

yes, it did that from the start, but the other thing is much easier, 
when you have many attachments to do.

I remember romano paolo tenca's 'attach, but it was resizing related. 
Ach, it was 'anchor ....

What if you dynamically insert new element into layout? Will it reattach 
itself? :-)

I'm not sure. I haven't tried it.

Petr, then you should not complain about VID, but about the docs. 
Problem is, we don't have anyone to write them. Brian is doing his 
best, but I don't expect him to be able to just do *everything* (user.r, 
testing, writing docs...)

Maybe I could help with docs, but not sure if I would be able to 
understand new VID to that extent, to be able to write one ...

My intention is to have more "explanatory" kind of docs, like in 
book, not just reference. http://www.rebol.com/docs/view-system.html
is good one for e.g.

i agree with you actually, but do you really have the time to write 
them? if so, i'm sure Carl would welcome you. :)

(btw i started doing easy-vid3 using easy-vid text as reference to 
make it "similar" in how it reads etc. but i don't have enough time.)

re free time. Not sure about the free time, but I don't want to sound 
like allibist. I might try. However - not in the case if you think 
that it is my method of how to get R3, as it is not the case :-)

you see, i don't think anyone has problems with you getting r3, we 
only have problems with you complaining too much about it - considering 
how much you do by just having looked a bit at the docs ;)

but, it's Carl making decisions - maybe you can talk to him directly.

i will tell him that you volunteered for the docs, if you really 
want to do that. (then you'll be the one to get complains for once 
;)

is btiffin there doing docs work?

yes.

been working on the vid docs for a few days already.

that's why i'm sure they'll improve a lot.

but i'm also sure he will need a lot of help.

My original proposition was to create alpha+ group, where everybody 
from here could get access to R3. That group would be isolated to 
not have access to Alpha group. Maybe only to see Alpha group Altme 
transcripts. Then you or someone else would visit Alpha+ altme, where 
would be one special channel for you, with summary prepared. That 
way you could prevent main alpha group from being flooded, yet you 
would be able to get some new bug reports ...

I think some ppl here are eager to get early R3 access ...

if Brian agrees on me to help him with Docs, I will accept ...

ok, so talk with brian first. then let me know and i'll talk with 
carl.

ok

I'm more than ok with sharing.  :)  It is part of the nature of wiki 
work...anything written can be edited  by anybody, anytime, no questions 
(other than password) asked.  If it leads to more information, I'm 
all for it.

Petr;  One word of caution.  In a support role; getting invited to 
the REBOL 3 kitchen, efforts have to be made to not bother the cooks. 
 It's hard, (really hard) but trust the chefs.  :)

I just re-read that post.  It's not hard to trust the chefs...it's 
hard not to bug them.

I just re-read the re-read.  It's hard not to 'want to' bug them.

Someday I'll learn how to type what I'm thinking...maybe by thinking 
what I'm typing.

Brian - I exactly understand what you mean. The bad thing is, that 
when you feel you have something to say to the design itself, you 
can't, or you don't want to, to not spoil the chefs. But - I will 
write docs only to desing I have 100% trust into. So far I have some 
worries. Those are more philosophical ones. E.g. worst part I read 
so far was 'tight command, which imo has bad influence on how VID 
code "feels". So - at first run, I will try to read most past discussions 
and try to understand new design philosophy. There surely are differences 
to VID2, mostly that styles seem to be organised in groups (columns). 
I can't e.g. see VID2 keywords like 'at, 'across, 'below, 'return, 
etc. - so, how I said - I first need to study the design. Then I 
will have some questions. 


I will ask those questions to Gabriele privately, to not flood the 
group, and because he is master designer. I think that guys managed 
to create strange atmosphere here. Since when is the design a closed 
effort to those who are interested in the design process? I don't 
remember it happening even with View 1.0 - ally mailing list. Everybody 
interested could reply at least on mailing list - no wait and see 
mode. That is exactly why I asked for the design docs first, althought 
I understand Gabriele's point of rather coding first. But the aproach 
of "watch, but don't spoil" excludes others from the design.


So once again - if I find new design unpleasant to use, difficult 
to use and explain in the docs, I may also departure from the effort.

Petr, well, there must be one designer. since we already had like 
7 years of feedback on the design of vid, i'm not really sure much 
more is necessary, but we're always listening for comments. your 
problem is that you always make assumptions and then complain based 
on your assumptions. please stick to facts. the fact is, that i've 
been in the rebol community since 1999, and I have implemented many 
VID apps. I read the ML, I read here every day, I read reboltalk.com, 
I read every ticket in RAMBO. i'm not really sure you know what vid 
should be that much better than me or anyone else here.

Design by committee doesn't usually work well.

Gabriele - lol. I accept your pov. But how is something I don't necessarily 
like being an assumption? I of course agree with you, that you are 
pretty much skilled person, based upon your REBOL experience, but 
apparently also by using (coding for) MUI on Amiga, LaTex, etc. My 
issues come from different perspective. I have no assumption how 
VID works internally, but that does not prevent me from seeing single 
syntax of some commands for e.g.

Graham - I understand that argument about "design by committee", 
that is OK.

My opinion just is, that whole design process could be two staged. 
E.g. ppl here could get access to transcript from alpha group chats. 
Ppl could also talk about it on ML. And why you think someone here 
on on ML could not raise some valid input? :-) It would be then on 
Gabriele or anyone else to use that input from userbase, or not, 
depending on "free" time to read it. So much for the organisation 
...

Now back to VID and syntax. It is now for you Gabriele, you surely 
will understand my reasoning. I don't mind if you don't agree with 
me. We are here not to necessarily have identical opinions ....

Let's say I am very average rebol coder, and that I also had one 
person, which I taught REBOL, VID specifically. I saw various VID 
code in the past, some was pretty and self explanatory, some was 
more messy. I e.g. liked simplicity in most of IOS reblets. The ugliest 
design in VID2 is a list for me. Thru all those years, I catched 
several ppl, to not really get it. It is kind of "usage pattern", 
and if it repeats, then we should think, if the aproach is best for 
the user. E.g. list style assumed cnt word in its block, and it was 
really confusing.

When teaching VID, my basic understanding was, that Bobik generally 
liked it very much, unless he had to touch its internals. The last 
escape was 'with. Creating new style was mostly a show stopper. What 
I and even him really liked, were facets. It is like the last easy 
chance of how to move upon the surface (VID), without the need to 
go under (View).

So my preference for the particular style is - use facets, as much 
as possible, no often usage of 'with, if possible.

What I speak about here is mostly feelings. But sometimes how we 
feel about the code for the first time also might mean, that we either 
stick with the tool, or we leave it. If I can see few lines of VID 
code and not being able to understand what it does, unless there 
are comments or the need to go to the docs, then it is not good for 
the tool. It should be mostly obvious at first sight ....

To better understand my very general concern, not concrete complaint. 
Let's talk simply command usage, e.g. zip:

zip.exe what -a param1 -b param2 param3 -c param 4 
zip.exe/a/b/c what param1 param2 param3 param4


As you can see, in REBOL there is much more emphasis put onto user 
remembering the order of the paramteres, whereas in the first example, 
user simply takes desired parameter, and in THAT context, specifies 
the parameter value. It is shorter path, and user does not need to 
follow long patterns.


VID, in relation to above exple, might or might not be similar. We've 
got facets, which too, allow immediate context modification of particular 
parameter. For me facets are one of the strongest aspects of VID 
semantics and how it relates to lower layers.