list-style: event questions

the

once and

to

list-style an

concept.

Hmm...

See below.

do

objects

The event hierarchy as I understand it is. (1) Window (2) Face (feel) My guess is that the operating system created window receives all the events and then View converts these two REBOL events and dispatches them to the appropriate face. Not all events received by the window are dispatched - I think View does some interpretation and culling of a lot of raw events and instead sends a more abstracted event to the face (eg. by calling engage).

In vid-ancestry, right click on a style to see the feel for that style. The program identifies the feel object being used. Have a look at them for button, check box etc. The vid-ancestry program will help you see how the various styles work and which have event handlers (FEELs). The indentation shown in the program is used to indicate how the styles were derived from each other - further to the right is more specialised.

yet.

over the

it. You *do* need this event - and I don't think you can remove it. It is probably the one that draws things on your screen. It or something related evaluates PANE. Allen wrote this a couple of days ago which is relevent here (the key phrase being "face iteration"):

The idea is that when you set the PANE to a function, the function gets called to dynamically generate the screen image. Don't get trapped into thinking that many faces are created - this is not the case. Actually faces are "rubber stamped" to give the illusion of many faces. This iterated face (calculated pane) approach is very powerful but comes at a processing cost. The function appears to be called very many times. LIST uses this method in order to implement SUPPLY. An easier style to study is TEXT-LIST which also uses this technique. LIST creates a function based on your specification. TEXT-LIST has a built in function text-pane so this makes it easier to understand. To see the definition of TEXT-LIST do the following program and click once on TEXT-LIST. If you work out how TEXT-LIST is built it will help you understand how LIST works. do load-thru http://www.codeconscious.com/rebsite/vid-ancestry.r Regards, Brett.

Hi, as you mentioned we have a (1.5) Dispatcher step. And that's the interesting one. How does this work?

Ok, I got this program. Very useful for understanding VID! AFAIUIN (as-far-as-i-understood-it-now) VID can be devided into two big blocks. A set of styles that are face objects with predefined words and values. And a set of interactor objects (named feel) that can be attached to styles. But not all of those interactor objects can be used with every style. Is this correct so far? The benefit we have is that we can reuse those feel interactor objects. BTW: AFAIK VID only uses one namespace, or was this layout? How are the different namespaces constructed? And what kind of namespaces do we have?

Hmm... I like the concept of "iterated faces" but would like to think of it as user of VID in a very simple way: LIST utilizes the "iterated faces" concept and the 'supply function gets called for each (real or virtual) face that's been calculated. With this in mind, I would expect that the supply function only gets called of the list is redrawn and I have to supply (!) data for the face. Adding a feel/over interactor to the list would enable a callback to the provided function in the case the mouse it moved over the list. But this doesn't necessary needs to call supply. When moving the mouse, no new data needs to be supplied.

Yep. But it provides a lot of space for optimization. For example if you click on a button that expands, the function can directly start with row 7 for example and doesn't need to start from top. Robert

interesting

I dont know. I assume it is compiled in to View and therefore to be considered as magic. :^) RT provided hooks into it with event functions (DETECT).

The

I'm glad! :^)

set of

of

all of

far? Yes I think that is pretty reasonable. Except that the interactor objects can be attached to any face. VID styles are templates that are used by the "face factory" LAYOUT to create faces.

Yep.

By namespace, do you mean setting face variables? LAYOUT sets the variable usually in the global context, but you can wrap an object context around LAYOUT too. For example: ctx-gui: context [ button-var: none lyo: layout [button-var: button "test"] ]

== button

it as

Yep, SUPPLY simplifies the interated face concept for users of VID.

alled

I

redrawn

The pane func gets called in two ways (1) where index is a pair! in this case an integer should be returned and (2) where index is an offset in this case a face should be returned. (1) maps offsets to virutal faces (2) returns the face to be rendered. The face to be rendered can be the same face as previously returned (for previous row say) but with some facet changed. I think the redrawing needs to happen far more than you are expecting. Imagine it from RT's point of view, how do they know that you are not changing the look of the iterated face when you move the mouse over it?

doesn't

to be

FEEL does provide behaviour handling (the feel of "look and feel"), and the face facets (including PANE and a pane function) provides the look of the "look and feel". For a modified LIST style you may be right, but how are you going to communicate the change onto the screen? How does a FEEL make a change to the look of a face? The answer - it changes a facet of the face. But a pane function (and supply of list) *is* a facet of the face - it defines what the face looks like. What I mean is, if you really wanted to the handle mouse events in FEEL that are currently being acted on by supply then you would need to maintain a block of faces. If you do this you would put that block of faces on PANE and so you would not have an interated face anymore. You need to write your own style. This was what I was trying to do with my grid stuff: http://www.codeconscious.com/rebsite/face-grid-demo.r http://www.codeconscious.com/rebsite/face-grid-demo2.r What I found really helpful was to create very simple minimal examples and put it print statements to see when things happen. For example, you might like to play with this which was one of the small scripts I used while learning the events. REBOL [] view layout [ b: box "A Box" forest rate 00:00:10 with [ pane: func [face id] [print ["Pane Render" id]] feel: make system/view/window-feel [ redraw: function [face act pos] [a b c ds] [ print ["Redraw" act pos] ] detect: func [face event] [ print ["detect" event/type] event ] over: func [face act pos] [print "over" act] engage: func [face action event] [ print ["engage" action event/type] if action = 'time [ print "show face" show face ] ] ] ] do [print "after spec"] pad 30x-40 box "B Box" brick feel [ over: func [face act pos] [print ["B Box:" act]] ] do [print "focus now" focus b] ] Regards, Brett.