World: r3wp

do we still need all - redraw, detect, over, engage? (just asking 
:-)

Pekr, I don't know. What actually calls those four functions?

View kernel

Then I guess we need them?

I e.g. don't like 'over. Maybe they are there from arcane View period? 
;-) Once you press mouse button and do 'over, it no more goes into 
'over iirc, but engage. Then I wonder, if having native 'over was 
not meant only as a helper because of speed? But I regard it inconsistent

Then it leads to special sections od docs, as Note: use 'engage for 
drag and drop. For me, the 'over, as is, is unnecessary complication 
- you have to explain it, and it could be done in 'engage too.

btw - 'engage, for me, is not good word selection. Well, I am not 
native english speaking person, but even after all those years, I 
don't know its exact meaning, in relation to events ...

I'm not sure either. Replacing the current FEEL system would be a 
tremendous amount of work. I was originally thinking more in line 
of extending it to those placeholders. I'm no expert on dialects 
and combining it with FEEL, but if it's possible to do, then OK. 
:-)

Hang on a minute.. The big revelation I had above about using REDRAW 
instead of DETECT was probably premature. Of course I must have experimented 
with both ways a long time ago and I would have settled on using 
DETECT for a reason. You have to be careful in REDRAW to avoid recursive 
SHOWs etc. It's worth more experimentation, anyway.

I tried some things with REDRAW, but was only more confused than 
before as it now completely refuses to redraw the contents.

pekr, the way the feel is built is very optimised.  there are reasons 
why engage separates the over.  I just would like access to the func 
which splits up the calls to feel. which is what I did in regraph. 
 since all events are virtual I was able to separate them differently, 
and support drag and drop directly in the graphic element's feel.

redraw realy slows down performance and can be a very dangerous memory 
clogger to.  when I replaced (long ago) all redraws in VID with better 
code in the actual engage and other feels, many views started feeling 
snappy when they had been hogs before.

I experimented a stream system for glass and it works very well. 
 it changes the way we approach events and can allow plugins to manipulate 
the way events are handled (and adding handlers for those changes) 
without the faces even knowing.

basically, each event is passed down a stream which applies the event, 
changes it or even creates new events out of it.

again, the speed is no concern as one view refresh is 10000 times 
slower than anything I have ever thrown in the event loop itself.

each node in the stream handles only one condition or type of manipulation. 
  the most obvious way to show how this is cool, is when you handle 
keys.

you can have a special node in the stream which replaces certain 
strokes with others... executing macros, or inserting a whole stream 
of text, even if the app doesn't really support it.

so you could insert the clipboard right in the inputs instead of 
having to support it explicitely in the various face styles... as 
a high-level example.

I even realised that we could add drag and drop OVER a fully working 
apps, sending the events to an external handler.. this allows things 
like interactive face manipulations while the app is running...  
:-)  cool for visual app dev... and its completely non-intrusive 
to the code of the running app.  the app just never receives certain 
events when a series of events occurs... and no need to play in the 
face's individual handlers either  (which is the biggest feature 
IMHO:-)

is that what liquid does?

I built the stream using a purpose built liquid node.  liquid is 
a generic core reference for dataflow programming.

and it comes with a reference (and fully functional) multi-purpose 
node called a plug which allows you to mix and match many types of 
dataflow nodes using the same node.

I propose a very simple enhancement to BTN to the official VID to 
allow the inclusion of images directly via layout. It adds 7 lines 
of code to the BTN init: http://hmkdesign.dk/rebol/img-btn/img-btn.r

Please study the source for commenting/enhancements. Thanks.

I have a problem with field and key in the same layout:

view layout [
	field
	key #"t" [alert "key: t"]
]


If I click in the field and try to enter a "t", the alert pop up. 
I'm doing this under OSX. Is it the same on other versions of View?

Geomol, it's the same in Windows

I'm wondering, why I haven't noticed this before, or maybe I have 
and forgot about it.

Is there a work-around?

Should it be RAMBOed?

yes, I think it should

I've put it in RAMBO.

I wonder if I should put my proposal in RAMBO now as well, but I'd 
like the code to be approved here first...

Tests do show under OSX that the color bug afffects the display of 
images in buttons.

It's the same in Linux, too - just came across it a couple of weeks 
ago

(Ubuntu)

*a couple of days ago

Geomol, here is a fix:

system/view/window-feel/detect: func [face event][
    either all [
        event/type = 'key 
        none? system/view/focal-face ; <--- added this line
        face: find-key-face face event/key
    ] [
        if get in face 'action [do-face face event/key] 
        none
    ] [
        event
    ]
]

view center-face layout [
	key #"t" [print "action"]
	field with [focus self]
]

(not well tested, but looks good.)

We should have checked RAMBO database - Romano posted this one three 
years ago
Do not detect hot-keys when a focal-face with caret is active
http://www.rebol.net/cgi-bin/rambo.r?id=3372&

hum... I have the draw docs for AGG but it seems the gradient fills 
are (as usuall with rebol it seems) so documented, such that We have 
no real clue how the values change or what are the basis...

has anyone done some complement docs to describe things like the 
offet and grad-scale ?

ok... the examples after give a few clues...

hum... is it just me or should the minimum colors needed for the 
gradients be 2 ... is there really a reason why we need to put 3 
colors?  its seems like it messes up most of the fills...

yes, I think gradients are quite hard and non-intuitive to do in 
DRAW

hum... a yellow green blue gradient  give me a ring of BLACK right 
in the middle... not what I call very precise... maybe cyphre could 
explain the maths behind the gradients so we can understand  what 
we are doing?

somehow, it seems like its missing a color blend mode selection, 
multiply, add, screen, etc. right now its a ramp which fades to 0 
on each side, such that when two successive colors do not have any 
bit in common it creates an alpha channel premultiplication grey 
zone...

henrik... any tips you can give me to make it less painless?

since you've played with it a while.

no, it took a lot of fiddling to get things right. I only played 
a bit with Gradient Lab, but it's not very flexible.

it seems like using alpha gives better results, when combining with 
bg colors.