World: r3wp

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.

at best it only works for very simple layouts

just copy/deep the style :-)

so where are you at now?  1% complete ?  :)

something like that, i only made tests :(

But it works fine in my brain :)

copy/deep Steeve/brain

== ERROR: stack overflow,  reason: brain too deep

if only

much like, division by zero

Maxim, I have hacked together(in fact it was lurking on my hdd for 
couple of weeks but I got to publish it here today) a test of one 
concept which IMO could solve part of your requests regarding 'access 
to DRAW elements' etc in R3. It can be also handy when you need to 
manipulate content of complex DRAW blocks...or even be a base for 
scalable vector graphics editor...or....I think there is relative 
big potential of usage :-)
Just try to run:
do http://www.rebol.cz/~cyphre/scripts/r3/tests/draw-shapes.r
in your R3 console.

BTW The demo also features pixel precise object masking and optimized 
redrawing of DRAW objects just to prove we can do lot of things even 
at the higher level.

The file contains couple of predefined objects but the main code 
is very small like 4kB so it should be easy to see my point. Hope 
this could help a bit to someone.

That's excellent Richard! Heavy on the CPU, but still...

cool to see, what even non-HW accelerated View can do.

(found a way to have time events)

Gregg, hmm...just checked the CPU usage and it looks like some regression 
in R3 view timers to me.
in R3 (2.100.97.3.1):
forever [wait 0:00:00.1] eats 10% of CPU 
forever [wait 0:00:00.01] eats 100% of CPU 

while both tests in R2 eats nothing.

Cyphre - are you sure?

IIRC, there are two modes for the timers, depending upon needed granularity. 
You measure two different times ...

http://www.rebol.net/r3blogs/0293.html

Plus, those mltimedia timers that people keep talking about use more 
CPU.

as for Windows, we know which timers are best, right? IIRC those 
were queue timers, but Carl said, that R3 timers are already OK

Pekr, not sure what you mean by two modes. I believe in Windows R3 
is using one method using the high-resolution timer using QueryPerformanceFrequency() 
-  http://msdn.microsoft.com/en-us/library/ms644905%28VS.85%29.aspx
Which should be more precise than R2 and it looks it  works OK.


The problem I see is why the CPU should be at 100% when I'm forcing 
the loop WAIT for 10ms which is plenty of free time. Isn't it?

http://www.rebol.net/r3blogs/0088.html

A more accurate post on what's going on.