World: r3wp

I'm having a stupid day where nothing works, so I can't do any work 
right now. I'm not sure it's a good idea to just wrap any flow engine 
on top of the GUI. The idea is simply to . We have to remember that 
it's about the idea

ok, AltME doesn't work either...

The idea is simply to make it very simple to interconnect faces. 
We have to remember that it's about the idea, not that a really fancy 
flow engine is the solution.

Also I'm being slowed down because of a project that I'm doing for 
Robert that takes time to finish. But please, continue the discussion.

we will, and as I informed you privately, Carl will hopefully resurface 
soon too ...

where is actual/latest VID 3.4 code stored? I would like to see, 
how 'attach works, and what it allows, then look into your docs, 
and try to think about it for a while ... well, I will most probably 
not come with anything anyway, but I would at least like to understand 
what we area talking about here ...

you can see it inside R3 chat

Steeve, how's progress on the r3 gui chat client?

I have spoken with Carl in the past about liquid, he REALLY likes 
the concept, he was mezmerized when I did a quick demo of it at Paris 
devcon.


But at that time, I wasn't trying to convince him because I didn't 
have enough real-world experience using it, and still had a few reserves 
about it myself.

Adding liquid to R3 is actually something Carl looks forward to, 
we chatted about it.

A lot more world experience is needed before something unknown is 
added to the GUI

The nice thing about liquid is that its an API more than anything 
and you can model it to do alot of different things, by just changing 
a few properties and implementing one or two functions.


All the nitty gritty is already taken care of and you don't have 
to play around in that unless you really want to create special and 
ultra-optimized nodes whih I very rarely need to do myself.

Especially something that is hard to understand

Remember that Carl rewrote vid as he found Gab's vid too hard to 
use

yep.

Although easy to use as a design aim contradicts his new stance that 
Rebol is not for everyone!

the trick with adding Liquid to R3 VID is to integrate liquid INTO 
VID and not the other way around.  in the VID dialect, or as a few 
function calls which just basically create a predefined node type, 
and links it up.

Graham, i try some idea on my own GUI currently

Your own GUI?

in my soon to be released application, the dataflow aspect of the 
code is less than 20% of the time spent, yet it represents at least 
80% of the actual usefull software capabilities.  


most of it was fixing View and VID themselves... the styles, the 
event mechanism and bugs, AGG bugs, enhancing http, etc.

i made some in the past, but they all died before adulthood

so genetic defects?

probably ;-)

all of these guis and none of them complete ..

an example of a very complex system which was made 100% robust is 
this:

-an image is used as a background, cropped , transformed and displayed 
within AGG

-we need to overlay an text area over the canvas, but its all AGG 
and its contained within a graphic element.

-we create a face which is a text-area, LINK it to the coordinates 
of the graphic element.

-the face is then converted to an image on the fly everytime the 
coordinates change (even rebuilding the text wrapping interactively)

-this image is added at the proper position with the AGG draw block 
as an image with coordinates.

Currenlty, i try a new way.

No VID engine, just an event handler and Gobs as agents talking with 
their environment.

focusing on the text area reveals the text-editor face
unfocusing, renders the face as described above.


but because everything is linked, the text-area face even resizes 
& moves automatically when we resize the graphic element without 
needing to unfocus it.

had I tried to build this system without Liquid... 
  -I'd probably have a very brittle textbox.
  -one that is VERY hard to improve.
  -it would lack a lot of the interactive aspects about it.

i decided to throw away any speed constraint to promote dynamic arrangement

it's slow?

i will be at first

each gob having a lot of methods and properties

each gob having a lot of methods and properties

but then, I will build agents to optimize arrangements dynamicly

so object oriented gui?

If it's slow .. just get a faster cpu

yep

or use liquid to optimise it.  ;-)

it's what i think now

steeve, I think you'd like

.. you'd like my glob engine (only R2 for now).

the opposite principle has been tested with area-tc. Cul de sac.
(i mean, having a fast engine (but huge and hard to maintain)

The guis that work are object oriented ...

It's just too hard otherwise ...

@ jocko on rebol.org there is a working version of liquid and a small 
demo of how it can be merged right into VID called blood.r

it creates relationships between MANY text fields, which become integer 
fields because of the data types of the basic liquid values.

and i don't like the need of  a phase to construct graphical objects 
from read-only specs.
All the GUI we had so far, act such.
It's an bad...

bad concept

its why I'm pushing for graphic element as a lower-level api for 
AGG right into view.

to my mind there should not be difference of design between a style 
and a face.

A face is an instantiated style (copied and just showed) , tha't 
enough.