World: r3wp

i think that the latest versions don't, but there may still be cases 
where that happens.

to be safe, you can view/new, change feel, then do-events.

Gabriele, I see your point: The user might want to enter some data 
in a field, but part way through think of something else and leave 
the field to attend to it, then return to the original field to complete 
the data entry. Finally the enter key will do the face action which 
can validate the field.

I think your solution using REFOCUS is a good one.

Henrik, welcome. Just look in source of VIEW to see how it sets the 
window feel. Gabriele is right, nowadays it shouldn't cause much 
trouble.

Are we still going with 'feel like it exists today, even for R3?

I hope it will allow more granular events.

I hope too. I don't like mega monstrose 'feel. It does not scale 
well. On one hand, you can code everything from one place, on the 
other hand, it is more handy for "style authors", than end-users 
...

Ah, but maybe by "more granular" you meant receiving events more 
often?

No, more different kinds of events.

I think personally that FEEL is very non-accessible to users and 
non-extensible. You can't easily add a simple thing to a feel, like 
when you create a style from a specific face. If you want single-key 
actions from a text field, you have to dive into the feel code, study 
it, know how feel and events work and then add your code. This is 
probably more an issue with the feel code itself, rather than the 
concept of FEEL.

Ah, then we are on the same wave. But I was not able to defend my 
opinion to e.g. Anton in the past :-) So surely rebollers will differ. 
For your own kind of style, e.g. animation, you might prefer current 
aproach. But I visited recently my friend, who started to learn Delphi 
some 2 months ago, and he already did nice app in it. The most missed 
feature of SDK is - no screen painter, lack of crucial styles, lack 
of proper style behavior (just try list-down here in AltME, you can't 
close it by clicking outside, esc, etc.?), and most ppl are really 
used to - on-double-click, on-left-click, on-over, whatever ...

There should be a ton of placeholders inside the feel code, to let 
you easily set those placeholders from within layout. I know this 
is possible to do.


view layout [field 100 single-key-action [print face/key]] or something

maybe: feel [

ah, enter ;-)

LIST-VIEW has a lot of different actions that let you set what it 
should do in particular situations easily. Every single VID element 
should have that. In fact there should be an abundance of placeholders 
for actions, every one that we can think of.

feel: [
on-single-key            [block of code]
on-left-mouse-click [block of code]
on-double-click        [block of code]
]

yes, very simple.

What I just don't know - what if you would like to serve e.g. holding 
down shift key and holding down left mouse button? e.g. for dragging 
something? I mean - you need both functionalities of on-something 
- how do you mix code then in those code-blocks?

So to use REFOCUS:

view layout [
	field
	field with [
		refocus: func [shift /local new-field][

               new-field: either shift [ctx-text/back-field self][ctx-text/next-field 
               self] 
               action self data
               focus new-field
		]
	][
		; action
		print "validate" ?? value
	]
	field
]

That system would be even inspectable, extensible dynamically, not 
like current 'feel, whish is "just rebol code"

Pekr, then they would work as flags. You should be able to access 
from within the code block, which qualifier keys are pressed. Binding 
the code automatically to the feel object would let you access the 
variables and events in the feel object.

yes, setting flags .... nice ...

I would even simplify low-level View aproach - no native redraw, 
over - it could be part of one feel, no?

Current feel objects can be inspected and extended dynamically.

I think the feeling is to have more higher level types of events 
derived from the raw event stream and provided to you in a more separate 
kind of fashion.

imo our aproach is non-intuitive, non-traditional. Feel is definitely 
not granular enough to be familiar to newcomers, who are used to 
on-something.

... maybe that is what we are talking about?

But if this is done for every face, would this not slow down the 
event system ? (Maybe it would, maybe it wouldn't, significantly, 
I'm not sure.)

As far as I see it, RT uses objects when speed is needed. They can 
map down to C structures better I think.

I don't think it's noticable. Every time I've done optimizations 
on events, removing redraws are causing the biggest slow downs. Everything 
else is hardly noticable.

Maybe we can make a dialect which maps the simple representation 
you've suggested above into an actual working FEEL.

yes, I start to like the aproach - one 'feel, like today, but dialect 
abstraction ....

You are probably right.

1. You have direct event handling with on-XYZ [do-program-code]

2. Then you have dynamic flags for, say, qualifier keys inside that 
program code, from the event system

3. Then you have face flags. Some things like size limiting a field 
should be simple. It can _probably_ be mapped to 1.

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.