World: r3wp

After sort of reverse-engineering DO EVENT to try to make some nifty 
things work, I don't want to have to do all that again. I'd like 
to be able to hook into the system. I think the min-face idea is 
really good.

I'd love to have a non-vanilla input stream.

support for (oh my gosh! ) middle button? up events, tracking cap 
locks, locking insert mode, etc...

min-face with only effect/draw and feel would be sweet.

word wrap queries (like in the old amiga api) within AGG draw would 
be cool too... as in, what would the size of this text (or any gfx 
element, for that matter) be with current font/drawing settings. 
 and how many letters from a string fit within this box ? wrapped 
or not.

With regards to min-face, when I spoke to Carl about this at the 
devcon we also canvassed the idea of a text-face, image-face, draw-face, 
etc which would have facets present / optimized for the primary function 
of the face. Carl seemed pretty keen to move away from the "one face 
fits all" type approach that currently exists.

I remember what I was trying to do: event transparency. That requires 
hooking into the event system.

It would be good to have an easy way to underline one character in 
a word (indicating the keyboard shortcut for that view face).

Yes, agree. But I think that been taken into account by the push 
for rich text.

a simpler method to change the feel for common operations, like trapping 
keys would be nice, so you don't have to redo the entire feel.

There needs to be a seperate feel interface for Look and Feel.   
One of the most common complaints that I heard from people using 
VID was that they were unable to change the way a style looked without 
rewriting the feel object.  It should be easy to alter or set either 
the look or the behavior of a face without altering the other.

I'd love to see a kind of a developers summit happen as RT gets ready 
to attack each part of REBOL 3.0 they should host an online meeting 
for several hours or even all day if that's possible so that we can 
all get together here on AltME or some online conferencing software. 
 That way all the developers will have a chance to let RT know about 
their wants/needs as they develop each peice of REBOL 3.0.

Ammon - that will not imo happen, as it never happened in the past 
:-(

I can always dream though, right? ;-)

:-)

Sure ? Remember the early View 1.3 project (december 2004 or was 
it 2003?).

Anybody has it's voice and could said what he wants to see and even 
come with the code.

That was a really busy time. I could hardly keep up with all the 
testing. But it was good. :)

.

This probably belongs to Tech news channel, but - SkyOS got new rendering, 
buffered, which much improved performance. It was done by one man 
in a short period of time. I do hope we get more advanced compositing 
for new View too :-) http://www.skyos.org/?q=node/508

I couldn't help but think that he's copycatting Syllable again...

REBOL 3 for the wiiiiiiiiiiiiiiiiiin

i'm inpatient to see it  ^^ and to get a ride on the new C DLL framework 
it ill include

I hope it is OK to post here a "technical question"?

some of you know my http://www.fm.tul.cz/~ladislav/rebol/lfunc.r
script defining a "luxury function" with initialization of "static 
variables". Example of the behaviour:

    f: lfunc [] [a: 0] [a: a + 1]
    f ; == 1
    f ; == 2


; etc. The behaviour is caused by the fact, that the initialization 
block causes all variables in it to become "static local variables", 
i.e. in this case A is static and local. It looked "natural" for 
me to define it this way.

and the question is?

Rebol3 is going to have CLOSURE-type functions for which initialization 
may be "cheap". Example:

    c: closure [/local a] [a: 0] [a: a + 1]

The difference lies in the fact, that the behaviour would be:

    c ; == 1
    c ; == 1


, i.e. the value will be reset to initial value every time a closure 
is called.

ah, sorry to interrupt you ...

Would you like to have this kind of initialization?

(because I may imagine some people saying this is "unexpected" to 
them, or expected, ...)

e.g. you, Pekr, would you like to have this, don't like, don't mind, 
any other option...?

How would a function be defined with the same functionality as your 
lfunc?

it is quite easy to define as a mezzanine, you may either have a 
look at the implementation mentioned above or ask me to post somewhere 
a simplified version (because the one mentioned above is probably 
more complicated than you would like...). Disadvantages of my LFUNC 
are, that it needs one special "static" context created when the 
function is being defined, which costs some time, e.g.

So your lfunc will still work in REBOL3, as it does now?

I am pretty sure it will, at worst with a simple modification

To understand it better...
I can make a function this way to have initialisation every time:
f: func [/local a] [a: 0 a: a + 1]

What exactly is the goal with CLOSURE?

example of the CLOSURE behaviour:

b: []
    f: closure [x] [append b 'x]
    f 1 ; == [x]
    f 2 ; == [x x]
    reduce b ; == [1 2]

; which means, closure variables somehow "remember" their values, 
compare it to:

>> g: func [x] [append a 'x]
>> g 1
== [x]
>> g 2
== [x x]
>> reduce a
== [2 2]

(where a was defined to be an empty block initially)

hm tricky. It needs some getting used to. And you question is, if 
closure should initialise very time? What will happen, if it doesn't?

CLOSURES are actually something like "more proper" functions, but 
their evaluation is "more expensive" (takes more time)

Will people understand the difference?

And is it usefull?

will people understand the difference: *if* they come into trouble 
when using FUNCS, closures may help them to obtain the desired behaviour

more "persuasive" example:

ahh, good point!

make-f-returning: func [x] [does [x]]
f-returning-ok: make-f-returning "ok"
f-returning-ok ; == "ok"
f-returning-wrong: make-f-returning "wrong"
f-returning-wrong ; == "wrong"
f-returning-ok ; == "wrong"

make-g-returning: closure [x] [does [x]]
g-returning-ok: make-g-returning "ok"
g-returning-ok ; == "ok"
g-returning-wrong: make-g-returning "wrong"
g-returning-wrong ; == "wrong"
g-returning-ok ; == "ok"

what do you say to this?