World: r3wp

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?

if DO-FACE cannot end-up triggering an ATTACH created function, then 
you are ok.

DO-FACE runs only reactors, so it unavoidably can.

I don't want the engine any more complex than necessary, but I also 
don't want to put the onus on the app developer (that is, me :-) 
to implement logic that is needed 95% of the time.

thing is, remembering who's been visited, doesn't help you if the 
engine allows cycles.  since who was visited first will (potentially) 
change outcome

Which is why the dataflow model is good, right? ;-)

I won't push for that, as I don't think Carl will go for it.

Carl likely won't allow any engines or state machines to be added 
now, so it has to be grafted onto what's already there. If it can 
be done in 5-10 lines of code.

its best to make the actuall API non cyclic directly.   


so if the various event/data handling systems can identify that they 
are being only required to RECEIVE data, then they know that they 
shouldn't cause any reactions of their own.


if your reactors are all basically derived from a single or few functions, 
then its not a big deal to implement.


but if each field has its own implementation then it can be quite 
a tedious effort, since you must revise all of them so they are non 
propagating.

and this has to be well documented to people writing reactors/actors 
always handle this.

The ATTACH and DO reactors are the only one that is able to run other 
reactors. You can of course freely design your own reactors, but 
we are basically relying on the content of the reactors to help avoiding 
screwing things up.

State machine: Not to be meant to be part of the GUI. The reactor 
code would just trigger the state machine than.

graph: As Gregg said, if we can link stuff, dataflow is not far away. 
And this will result in a constraint solver a la Excel. Which would 
be very cool to have anyway.

http://twitter.com/rebol3

Richtext ??

What's your exact question, Graham? :-)

The dialect is low level, i.e. not a mezzanine, so I guess some conversion 
work needs to be done.

Regarding ATTACH, perhaps it's best for now to leave it working as 
it is, as I'd like to keep it. One big advantage of reactors is that 
you can write your own very quickly and not affect the GUI system.

Anything releasable for us to try?

not yet, but I know Bolek and Cyphre are working hard in the background 
to complete the resizing system.

I t hink within the next 1-2 weeks a major milestone will be reached. 
host-kit with fully externalized graphics, resizing system mostly 
working and a couple of styles using it available.

An internal milestone?  Or an alpha release?

IMO this can be a next host-kit release.

i'm lost  i haven't being following here closely but why VID is externalised 
? well it always was and optional thing ... the main thing being 
rebol/core... so this tendency is made more clear. Will this allow 
 people to access the graphical side extension and modifies it independently 
of  rebol/core (the host ?). Are they other side package planned 
?

is it possible to know who work on what in the GUI topic and have 
a slight idea of the steps done and the steps to be done ....

sure:


Robert - DB interface, messaging, state machine, cracking the whip
Cyphre - Resizing, low level AGG, rich text, host kit interface

Me - Dialogs, form validation, database interface, reactors, messaging, 
state machine help system
Bolek - Styles, resizing
Ladislav - Resizing, state machine


The above is basically what needs to be done for the first customer 
app.

hum ..; can i crack the wip too ? it seems fun !!!

ok so then does ritch text is a really something to be set as default 
inside the VID extension or isn't it wiser to let that as a side 
project to make research about the perfect way it could be done... 
and we let in draw a set of basic commands related to draw (a revamped 
set ofcourse) for instance I think that a ritch text engine is too 
much for the syntaxe colored editor we made ... it's like taking 
a nuke bomb to kill a single little fly .... but such an engine by 
default can anyway open new perspectives. but what annoys me in the 
process is to do this  raw script -> conversion to ritch text dialect 
-> conversion to draw by the rich text engine ...  instead of doing 
this raw script text from file.r -> conversion to draw using parse. 
But maybe i'm wrong ... anyway one way or another i will do a port 
of area-tc. and i assume that if the rich text engine seems too much 
for me then i could still do my proper engine relying on the draw 
for text lower level instructions.... (not to mention i like the 
idea of learning parse through  experiements)

and if the rich text engine doesn't handle clickable link display 
how can we add that to the rendering engine ? for example during 
a moment Steeve planed to add to area-tc the hability to render url 
in the rebol header block in a special way  in order to have them 
click and open the navigator with tthe url you clicked over. in an 
open engine like area-tc adding this isn't difficult  but adding 
this to a black box called rich text rendering engine seems to me 
to be harder... but i'm certainly wrong ...

with rich text come a lot of  troubles like handling paragraphs resizing 
things etc... how and where images are inserted withing the text 
paragraphs etc ... Can at some point the image inserted within text 
can be a draw set instruction rendering (for graphics or SVG image 
rendering ) etc... how will that engine grow ?

if it's just a cheap intent to mimic rich text that will make people 
laugh but if it's a  main concern and a constant work then it can 
become something really awsome.

I don't think it will be a black box.. richtext will be part of host 
kit, I think. And tight integration of text rendering with richtext 
engine is good imho.

Henrik .. that's a big job everyone has.

shadwolf, I suggest waiting with further comments until a release 
is made, so there is an actual base for commenting on.