Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: list-style: event questions

From: brett:codeconscious at: 16-Apr-2002 8:16

Hi Robert,
> > The event hierarchy as I understand it is. > > (1) Window > > (2) Face (feel) > > Hi, as you mentioned we have a (1.5) Dispatcher step. And that's the
> one. How does this work?
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).
> > In vid-ancestry, right click on a style to see the feel for that style.
> > program identifies the feel object being used. Have a look at them for > > button, check box etc. > > Ok, I got this program. Very useful for understanding VID!
I'm glad! :^)
> 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
> 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? 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.
> 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?
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"] ]
>> ctx-gui/button-var/style
== button
> Hmm... I like the concept of "iterated faces" but would like to think of
it as
> user of VID in a very simple way:
Yep, SUPPLY simplifies the interated face concept for users of VID.
> LIST utilizes the "iterated faces" concept and the 'supply function gets c
> for each (real or virtual) face that's been calculated. With this in mind,
> would expect that the supply function only gets called of the list is
> and I have to supply (!) data for the face.
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?
> 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
> necessary needs to call supply. When moving the mouse, no new data needs
to be
> supplied.
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: 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.