World: r3wp

Enter private message in #8

ok, then pu is for private messages in his folder, while pp is for 
private messages in the current folder.

makes sense ...

Henrik - as there is not much comfort in RebDev chat - not using 
other gob types contradics their purpose, no? I do understand, why 
keeping GUI desing simpler might have advantages, but stating that 
effects are not needed so far, because Draw dialect can serve us 
well for GUI purposes, might also mean, that we could discard effect 
pipeline? :-)

No, it just means that I have not needed effects yet. I think they 
should definitely be possible, but we have to be careful not overexposing 
it. MAKE-GOB could introduce a level of control that we don't want 
in a style, making a single style a big mess with hundreds of lines 
of code, because you have to reference GOBs.

So far GOB management happens in 20-30 lines of code in one specific 
place in the R3 GUI design. It's very tight and controlled and by 
adding an effects GOB there, would make sense in the R3 GUI design.

Maybe it would be best to add 'effect and 'rich-text functionality 
to draw directly, as image is there too anyway. Would make it for 
one combined pipeline. Dunno how it would make low-level implementation 
more complex. Then we could discard other gob types ....

I note that in JS we can fade in visual objects ... will that be 
easy to do ?

Dunno, but I would like to have transitions and wipes available. 
It could be done even nowaday, just look at Jeff Kreiss present.r 
script. IIRC it is available on rebol.org. It contains whole dialect 
for movement, fading, etc. What I worry about is - low speed of REBOL 
for such stuff, at least in REBOL level and without Rebcode, we can 
better forget it. We also need to implement different type of timers 
etc. But generally - dunnof if we can get smooth results without 
real HW acceleration ....

Graham, each GOB can set its alpha channel with 1 integer directly. 
I don't think this is exposed in the UI yet, but it wouldn't be hard 
to do.

Do you think that gradients could help us with progressive fade effect? 
I mean - not fading whole gob, but because of using a gradient, it 
would look like progressive fading. Well, for real transitions (and 
there are few demos out there), anything REBOL based (e.g. pick/poking 
pixels) is gonna be slow, unless implemented directly as an effect, 
or unless Rebcode in new form is back ...

I hope gradients for lines drawings will be implemented ...

I'm not sure that would be simple to do unless you do it directly 
in DRAW, but then you will need gradients for lines, which we don't 
have yet.

It would help if GOB alpha was calculated per pixel as an effect 
and then we could do real alpha masks, but it isn't.

So - where do we write down our wishes for Cyphre to implement? :-)

Somewhere in rebdev. We have a high level GUI thread there. Might 
as well create a low-level one too.

I was thinking about CureCode for a while, as a "wish" requests, 
but not sure if we should "flood" it with such a stuff. Maybe a RebDev 
is better place, but Cyphre might not read it, because of its, well, 
"comfort" :-)

Just wanted to look-up some info about ReBin, as it is mentioned 
in recent March R3 plan, and found out following article:

http://www.rebol.com/article/0044.html


Pity it is almost 4.5 year old one. Hopefully we get it in upcoming 
months, as some features were really planned for ... sooooooo long 
;-)

Ah, damn, another big restructure of DocBase? :-) While Docs become 
more readable and graphically nicer, the person doing restructuring 
does not even distinguish Gabriele's GUI to Carl's one, so it really 
becomes an organisational mess and he ruined Carl's initial Docs 
for GUI ...

Can we somehow contact Kr bacon?

Is that _the_ Kevin Bacon editing R3 docs?

Question to R3 people:
In R2	>> LIST-DIR %/c	<-- will crash R2.7.6 
In R2	>> X: %/c

 >> LIST-DIR X		<-- will ask a security question to allow, and then 
 return desired results

In R3	>> LIST-DIR %/c	<-- will return desired results (no security 
for alpha R3a.37)
	>> X: %/c

 >> LIST-DIR X 	<-- will give ** Script error: invalid arguement: 
 %X
	>> LIST-DIR :X	<-- will return desired results.

Why do I need to put a : in front of my variable in order for LIST-DIR 
to work properly?  Doesn't seem to be intuitive, does it?

because of how path is defined (as parameter) in list-dir.

func [ 'path ...] instead of  func [ path ...]

don't know why this choice

Thank you Steeve, for checking into this

perhaps to allow this semantic:
list-dir c
instead of list-dir %/c
but it doesn't work

sh

sh

Steve, I'm trying to "capture" the source of LIST-DIR in a separate 
file, but I don't have the syntax quite right.

R3	>> SAVE %listdir.r SOURCE LIST-DIR	<-- donsn't work, I'm not sure 
how to sturcture this command

I got it
SAVE %listdir.r  :LIST-DIR

Try
  mold :list-dir
to get the source in a usable form

yep

Interesting,  MOLD :LIST-DIR returns the results inside of { }, where 
:LIST-DIR doesn't

:xxxx -- gets you the value of xxx
mold -- makes it a string

or you can use the clipboard
IN R3:
write clipboard:// to-binary mold :list-dir
(similar in R2)

I noticed that under HELP LIST-DIR, the arguments state 

    path -- Accepts %file, :variables, and just words (as dirs) (file! 
    word! path! string! unset!)

I get the first two ie  %/c and  :VAR-DIR, but what about "just words..."
Can anyone give examples of the third type of argument?

it doen't work currently, i think it's a bug, ask Brian before to 
post a new bug

it should work as-is to my mind
list-dir c
(same as list-dir %/c)

The relevant portion of the LIST-DIR source is this:
    switch type?/word :path [
        unset! []
        file! [change-dir path]
        string! [change-dir to-rebol-file path]
        word! path! [change-dir to-file path]
    ]
You should try SOURCE MORE for a simpler example of this method.

LIST-DIR is one of the console interactive functions, so it is acceptable 
for it to have an optional parameter without a refinement - otherwise 
you should avoid that method. The function you should use inside 
code, rather than interactively, is READ.

LIST-DIR currently needs work (mostly better formatting), but the 
behavior you describe is by design.

In R3, have we a function to replace a list of values by anorther 
one currently ?
(don't remember)

in a string

Can someone enlighten me: Will we have the Wiki and Carl's R3 docs 
side-by-side? Isn't that a double effort? I don't get it.

About LIST-DIR:

R3 have some UNIX kinda commands, like ls. I think, Carl was tired 
of typing:
list-dir %script
and just wanted to type:
ls script


But it doesn't work with /c, because it's seen as a refinement datatype, 
and ls doesn't allow that. It's a mistake, as I see it. You can do 
it by:

myls: func ['path] [ls (form path)]
myls /c

Thanks for your comments Brian, Steeve and Geomol

Geomol, refinement support sounds like a good idea, but it was left 
out on purpose because /c would work but /c/d would not. It is better 
to get people out of the habit now than it is to have to explain 
why /c/d doesn't work, over and over again.

Steeve, try REWORD - it is not a modifier though, it builds a new 
string.

There is a plan to add this as an option to REPLACE as well, and 
that is a modifier.

Robert, the R3 docs are a manual, while the wiki is community-generated 
articles and such. Not the same thing.

hmmm... reword doesn't fit well in my case.

i want to replace sequences of replace/all on the same string. I 
saw this scheme in many scripts (not mines of course:)

replace/all data ... ...
replace/all data .. ...
replace/all data ... ...

Cirst attempt could be:

foreach [this by] values [
	replace/all data this by 
]

but it would be slow.

hmm... it works with reword with an empty escape option:

>> reword/escape "Hello you" [#"l" #"L" #"o" #"O"] ""
== "HeLLO yOu"