World: r3wp
[!REBOL3-OLD1]
older newer | first last |
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. |
older newer | first last |