World: r3wp

waiting for everyone to report their bugs first so that you can fix 
them :)

that's the point of liquid... un breakable.. once it works... it 
just does

the entire gui is reflective.

how much code is it?

in this example... way to much, cause we are basically including 
very basic nodes and a core gui api, but if you remove that, in fact 
there isn't that much left.

with the external libs I am building (actually working on them daily) 
code use will be very small.  since the most complicated part of 
the engine will be wrapped within liquid-vid, and you will have a 
lot of example and reusable liquid classes to start off with.

I mean, we have to use liquified versions of things like min/max/sum/sub/append 
 funcs... there is no going around that.  but its like defining new 
functions... which are just as reusable.

ok, cool . just tried it out

try putting extreme values in ANY field, even non numerical, decimal, 
etc.

is everything MIT now?  Is the GPL gone?

all MIT

what really pushed me was that I realized that with gpl, you can 
even get kicked out of your own code.

its like a sticky fly trap.

beurk

notice how it even updates labels, colors, and buttons become inactive 
when you go out of bounds.

(+/-) are buttons

also note that it was the first time I tried to do this using liquid. 
 its not like an old code sample I refurbished...

all of this has to be wrapped inside a dialect !

in theory it should, but in practice, it depends.

I have built several systems which used dialects... but liquid allows 
so much variance, that its like building a dialect for functions...

the gross of the work is not in between the plugs... its the plugs 
themselves.

so liquid-vid is going to wrap most of the liquid code for the gui.

but a single function... liquify can actually perform 5 operations 
in one single line, including linking to any number of pipes at once... 
so there would actually be very little code gain.

dialects will be usefull when the use of the plugs is well defined, 
and your plugs  are pre-defined, then the dialect will effectivey 
shrink code size by a huge amount... but that's just like for any 
dialect use.

I guess we could make a generic dialect which uses a set of pre-determined 
plugs (a bit like a vid stylesheet) and just builds up a network 
a bit more easily...    this is planned....   the dialect function 
already has a name.... :-)

dilute()

so, this works for numbers and ?

anything.  the example just does artithmetics, bounds and mappings, 
but you can use this for anything.

an obvious example is a setup where you have a series of inputs, 
which are all linked to one plug which compiles them as an object.

if part of a gui, the "submit" button is inactive, until all conditions 
are met.

liquid-vid should provide this out of the box.  :-)

need to hook this up to rebgui

I also use liquid to build vast networks of AGG graphics for real-time 
interface creation... we are talking several thousand lines of AGG 
commands.

liquid-vid should make glayout and rebgui obsolete.

only if you can replicate all the widgets!

we don't  :-)

for example, in the blood app, there are no int gadgets.

all the label types, will just need one link to a different font.

grids are much easier (actually quite easy) to build with liquid, 
and in any case, its still faces... so importing a gadget is dooable, 
if rebgui doesn't depend on too much out of widget infrastructure.

skining will be dynamic (I mean you plug a color gadget and the whole 
ui interacts as you set the scheme).

btw, the reason liquid-vid is taking some time, is that the whole 
layout is built using dataflow !  :-)

I've been re-designing the wrapper around the system for a week... 
trying to find a sweetspot between flexibility and styleability.

Max, would your engine be good fit for a spreadsheet calculation 
engine? Steve Shireman wrote this nice tiny spreadsheet widget (http://www.efishantsea.com/nano-sheets.zip), 
I guess that pluging liquid inside would make a killer demo both 
for liquid and REBOL, don't you think so?

I looked at it a long time ago, but realised that its basically easier 
to start from scratch... cause if you remove the processing aspect 
of nano-sheets... there's not much left.

:-)

but once liquid-vid is released... really its going to be very easy 
to build up grids and a little equation builder.

Max, you should try to find a route to attach liquid to existing 
GUI like VID or RebGUI. By a dynamic hook or so.

Otherwise it's a all-or-nothing thing which makes it hard to bring 
liquid step-by-step into an existing app.

Overall, it still sounds like a multi-path constraint solver to me.

robert  liquid-VID  ;-)