r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Henrik
21-Aug-2007
[4251]
indeed it kicks ass. a very small example:

view [progress slider attach]


slider is attached to progress and will adjust it's length automatically.
Pekr
21-Aug-2007
[4252]
ok, let's fight a bit :-)
Henrik
21-Aug-2007
[4253]
and you get automatic resizing thrown in for free
Pekr
21-Aug-2007
[4254]
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 ...
amacleod
21-Aug-2007
[4255]
Sounds great
Pekr
21-Aug-2007
[4256]
Henrik - I saw some weird arithmetic expressions for attach. Just 
one question - does it allow named variables instead of integers?
Henrik
21-Aug-2007
[4257x2]
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.
Pekr
21-Aug-2007
[4259x2]
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? :-)
Henrik
21-Aug-2007
[4261]
I'm not sure. I haven't tried it.
Gabriele
21-Aug-2007
[4262]
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...)
Pekr
21-Aug-2007
[4263x2]
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.
Gabriele
21-Aug-2007
[4265x2]
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.)
Pekr
21-Aug-2007
[4267]
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 :-)
Gabriele
21-Aug-2007
[4268x3]
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 
;)
Pekr
21-Aug-2007
[4271]
is btiffin there doing docs work?
Gabriele
21-Aug-2007
[4272x4]
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.
Pekr
21-Aug-2007
[4276x3]
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 ...
Gabriele
21-Aug-2007
[4279]
ok, so talk with brian first. then let me know and i'll talk with 
carl.
Pekr
21-Aug-2007
[4280]
ok
btiffin
22-Aug-2007
[4281x4]
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.
Pekr
23-Aug-2007
[4285]
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.
Gabriele
23-Aug-2007
[4286]
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.
Graham
23-Aug-2007
[4287]
Design by committee doesn't usually work well.
Pekr
23-Aug-2007
[4288x12]
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.
Then we've got keywords for VID, which I like less. They are somewhere 
in your VID code, and mostly are as switches - 'at, 'pad, 'tab, 'across, 
'below, 'return. They are more difficult to follow, because they 
somehow "fly" in your code, and you have to look for them, to know 
actual state, when writing your code.


And now to styles - I don't like too much, if something outside my 
style, influences my style. So, how self-explanatory is "tight right 
off left 50% top 100%"? There are few possibilites, well, yes, based 
upon my assumptions:


1) the design, from my pov, is not right, and 'tight should be a 
facet to the style. We reach philosophical difference of object.show() 
or rebolish show object (or more objects).

2) 'tight does not affect real/internal margin of particular style, 
it stretches spacers used in group column model

3) the name is not self explanatory. Even first sentence description 
talks about margins. So why not 'margin or 'set-margin, which would 
be much more obvious at first sight ...
And you see, those issues might look as absolutly minor, for most 
of guys here. I am not language purist. I don't care much how you 
cook VID inside, but how will VID level code attract the eye of newcomers. 
We want to have millions of them, right?
Those aspects are nearly psychological, but judging upon my experience, 
when trying new stuff, I mostly follow following pattern - see screenshots, 
download product, install, try to run it with some examples, look 
at sources. Only if I am interested at first sight, I consult docs. 
I think that might be pattern of most newcomers .... if VID code 
will be obvious, they will stay and go eventually deeper. There is 
why I care so much for the "surface" of the things ....
Gabriele
23-Aug-2007
[4300]
petr: when i talk about "assumptions" you make - you make statements 
that sometimes have nothing to do with the current code or with what 
we plan in the future. you make them just by looking at some doc 
or something i or henrik said and then you "connect the dots" in 
your own way assuming that something is going to work in some way, 
or be limited and so on. most of the times, it's just the docs that 
are missing or the implementation that is not final.