World: r3wp

exactly.  I have never had the need to look at or use rebgui, ever.

can you make some deductions

I tried downloading it once and after tortoise svc started fucking 
up and slowing down my computer, I got fed up, and uninstalled it, 
and rebgui wen't along with it ... hehe

I can tell you that its pretty easy to make it work in vid, so it 
should be pretty easy to make it work in rebgui.

afterall, it's Rebol, view and data.

all you need to do is capture the action, send a message to the relevant 
liquid. if each control has a liquid which is responsible to set 
the control, when it receives data, they will update by themselves.

how about a one page example of two text lists upddating each other 
?

in vid?

well actually, you have to understand, that technically they don't 
update each other...  they really are sharing the same data.

by "the same data" I don't mean the same rebol block... but the same 
data in the sense of individuality... they are two different views 
of the same original data set.

so just don't do a copy/deep!

whenever one creates a change, that change is performed on the original 
data set, and everyone is made aware of the new data.

cause one data might be a string, another an issue, one a word, and 
still one a tag.

but they all share the same string information.

you could have a decimal range, and have it expressed in other formats, 
like colors, or sliders, progress bars... but they still all reflect 
the same original data.

change the page number in the field, the scroll bar updates by itself. 
 and vice versa.

one list might be filtered by gender, another by age, but add a new 
member to the list, and both will reflect the change... however it 
happened.

the advantage, is that there is no "global" understanding of what 
the data is being used for... each part of an application handles 
its own use of some data and really isn't aware of the rest of the 
application, and doesn't care.

doesn't have to.

vid

yes

normally you have to know that whenever the list changes, you have 
a slew of functions to call, labels to update, what if the cursor 
changes, due to some insertion, deletion, what if the current selection 
is deleted... all examples which have to be handled globally... and 
the more the application grows, the hairier it becomes.

that will be my next personnal project..  I promise.

its easy to do... but right now I am working actually.

so it's not that easy then !

liquid is not about less code... its about unbreakable and long-term 
feature creep indiference.

its not easy, because we have to mix three paradigms into one application.

and dataflow is a management layer, so patching a flaky event engine 
like view's has to be done properly.

really hard, I did blood.r which has 16 interconnected fields, in 
an evening.

most of the time was spent with non liquid related things... like 
vid.

hum... I seem to be getting the reichart syndrome... there is a *NOT* 
missing before "really hard".

which is what I was saying, it's not easy.

easy is a vague term.

I'd rather say VIEW is the problem.  since liquid is pure.

and perfect   ;-)

but no, its not "hard" its just not a 5 line affair.

so at what point is there a payoff?

most of the time will be spent by me cursing after view trying to 
get the list to work.

16 nodes?

8 nodes?

payof is in:

 -robustness.  there are NO loose ends, no forgetting.  its impossible 
 by definition.

 -long-term dev speedup: adding features doesn't increase complexity, 
 since all features are developped completely independently.

 -speed: properly designed, lazyness can make an application quite 
 fast, even for very complex apps.  obviously, there are worst case 
 scenarios.. like anything.
 

add a dialect in the mix, and then the code size will shrink a lot, 
but since REBOL itself, isn't dataflow enabled, patching liquid within 
other REBOL components doesn't really benefit from a dialect.  cause 
creating, connecting and processing nodes is really simple.

to get two gui lists to share a dataset, will take as little as two 
nodes.

as I said, the liquid aspect of it is trivial.  its the view aspect... 
as always.  and view is still simpler than most gui engines I've 
used in the past.

just wanted to drop a little note saying that I have been using liquid 
for the last few days developping a brand new application (which 
I am not at liberty to disclose right now)  ...


DAMN... its just soooo sweet... really... adding features is "add 
and forget".   not "pry-in and pray" I have been adding feature after 
feature, everything is interconnected, graphical, and not only does 
it allow me to move forward without ever looking back, everything 
that is liquified in the software is down right unbreakble and bug 
free. 


software source  has trippled in size and I have spent only about 
4 hours in a whole week's worth of coding for resolving bugs.  More 
news to come in a little while.

It is really nice, but would be even nicer if we could play with 
Licquid as well :-) This is teasing!

liquid is on rebol.org for the several years has documentaion too... 
what do you mean?  you mean you'd like to play with the application? 
 well YOU now have access to it  :-)  you know where  :-)

well, it uploading right now, so will be there in afew minutes (3MB 
upload)

LOL I missed that Liquid was on rebol.org. I thought it was still 
work in progress :-)

I would be very interested to see what you can build with it and 
how its done. Ive looked at the docs briefly but I did not "get it".I 
should re-read them I guess.

I will be releasing the first liquified api shortly, called paint. 
 this is a rebrand of the infamous glob engine.  This engine allows 
people to use draw, just like if it where faces, where individual 
graphic elements (or groups of them) can receive face-like events.