World: r3wp

And could we LINK to more than on target? That would be nice.

link is already used to fetch "reb content".

I see...

more than one target: you can attach as many as you can. doing it 
in blocks, perhaps can be added.

attach: [

 "Set state of a face to our face's value and performs its main function."
	name [word!] field [word! none!] our-field [word! none!]
] [

 set-face/field get name get-face/field face field our-field ; (none 
 is allowed)
	do-face get name
]

how it looks now.

What is FACE ?

a reference to the face itself

It's not defined in the above function.

Or is it defined at a higher level?

each reactor is converted to a function, where the first argument 
is the face and the remaining arguments are as shown in the argument 
list above

>> source guie/actions/attach
guie/actions/attach: make function! [[face value

    {Set state of a face to our face's value and performs its main function.}
    name [word!] field [word! none!] our-field [word! none!]
    /local
][
    set-face/field get name get-face/field face field our-field
    do-face get name
]]

; also VALUE is in there.

Ok thanks.

I think I would reword the doc string a bit for grammatical consistency.

It looks like it should be either "Set" and "perform", or "Sets" 
and "performs".

yes, sure

Does it actually set the "state" of a face, or is it really the "value" 
of a face ?

I changed the text, as that was inaccurate:


Set a field of a face to a field of this face and perform its main 
function.

Perhaps, to eliminate some ambiguity, it should be:

Set a field of a named face to a field of this face, then perform 
the named face's main function.

(Is "main function" really how it is described elsewhere ? I'm still 
stuck in R2 terminology, but I was expecting something like "action".)

there is no longer a single "action". what you do is state a reactor 
or a set of reactors and it's this set of reactors that would be 
equivalent to R2's action, in that DO-FACE performs that set of reactors 
in sequence.

and by main function, the idea is that faces can be accessed on multiple 
levels, i.e. you can also just run a single reactor in the face.

that is most useful, when working inside actors.

Ok, that makes sense then.

as I said and once again - I doubt that any such solution will be 
sufficient for all ppl, hence I am not sure it belongs to the base 
of theGUI framework ...

for cross-linking GUI elements, it might be sufficient, but for overall 
app logic? There would have to be list of possible update actions 
for each element possible change. The system I used in DOS ere had 
it exactly like that. And it worked even with grid for e.g. You deleted 
an item, and the update action was able to update your stock DB item 
related amount. The mechanism would have to be universal enough, 
because if it will not cover enough cases, it will not be used by 
developers, and will bloat the GUI code, as everybody will replace 
it with own version ..

 There would have to be list of possible update actions for each element 
 possible change.
 Could you give an example? Thanks.

Although I've implement 5 complete GUI frameworks, so far I've stayed 
relatively silent on the R3 GUI front cause I'm building my own framework 
and I don't want to interfere with the R3 system.


but I will pitch in here and say that what Henrik proposes is a good 
idea (I use the same name for a relatively similar feature), though 
it needs one thing if it is to be usable by newbies.


a way for do-face NOT to call attach.  the reason is that if you 
want several cooperating controls, they must not create feedback.

you mean circular references?

for an imperatively driven system like the R3 system, you might want 
to look at how Amiga OS's BOOPSI system managed this.  its relatively 
easy to code and allows for a much more robust data interchange between 
controls.

yes amongst other things.

yes, we could use that. this is one reason Carl didn't like it in 
the first round.

BOOPSI used an intermediate structure which acted as a controler 
to which you connect everything that has dependencies. then you call 
do on IT.

Henrik - one field change might cause change in multiple other places, 
not necessarily GUI related.

my old VALVE liquid system was similar to this and I could easily 
have 30 interconnected controls in realtime, all refreshing, some 
even generating data which where used in other parts of the gui (like 
backgrounds).  so you'd have a control control and the whole "stylesheet" 
would updated interactively.

Pekr, arranging reactors properly should solve that problem.

an other simpler way, is to have a refinement on do-face,  /REACT 
 which indicates that its being driven from another control.  so 
then, you make sure that this face's do-face doesn't follow up on 
its own.

though this doesn't allow all of the tricks, it does solve circular 
references.

yes, I was just thinking that.

valve worked like that, pretty much.

the new GLASS engine, using dataflow for every aspects of itself, 
doesn't have these circular reference issues... its plugable at the 
data level.

so you can plug the graphics directly to the data, and/or any sizing 
or intermediate processed data together.

Henrik, let's discuss this idea with Carl and than Lad because it's 
all about graph-theory how to solve / detect circles, loops etc.

Petr, the app logic shoudl just get a trigger from the GUI (subscriber 
pattern) and than do what ever makes sense.

We have a VFSM (virtaul finite state machine) imeplementation for 
this.

Robert, I'm not sure how much theory there is in it. It seems more 
to be a feature that needs to be added to the reactor evaluation 
part.

I.E. 2-5 lines of code in the right spots. Of course preferrably 
with minimum performance loss.

but Carl may have some ideas on where to do it. I'm not sure we need 
to delve into adding whole engines and state machines to do this. 
75% of what is needed is already implemented.

State machines are good.

I also think that this is the kind of thing which should be kept 
simple to a minimum.  this above simple procedure covers the majority 
of cases.

if users need something much more complex, then they are fully able 
to implement their own within the reactors.


IMHO, this is a generalized "helper" for those little things which 
aren't fun to code manually and for which a simple API does the job.

Maxim, DO-FACE doesn't directly chain into other DO-FACEs. I'm therefore 
assuming that we need to somehow store the caller face?