World: r3wp

if they wasn't we counld not use variables in our draw blocks

The dialect itself evaluates some stuff.

Henrik, I admit I have not read the whole discussion but I have a 
question:

Does this system caches data somewhere before updating the record(s) 
or data is immediately written on the record field ?

When an user edit a file it must be checked for proper input

When multiple fields are edited they may have a relationship on consistency 
and there is a mutual validation

When you save the recordset  there could be errors on writing and 
the whole transaction need to be discarded instead of being partly 
written.

validation is not a part of the UI yet, but it will be.

the idea is simply not to submit the data until the form is validated. 
I've not decided yet, but validation could be a reactor, the way 
things are shaping up right now.

P: Validation ('import) and Active Record (RoughCut) are essential 
components of QM.  Validation (along the lines of 'import) could 
easily be part of a panel/layout's specification...

Ok Henrik, please do not forget a "record modified" trigger for the 
UI. In multiuser enviromnent it is really useful to know if the record 
has been modified by someone else.

hmm.. yes, will see what can be done.

any new screenshots? :-)

Henrik - what was last status of resizing? Carl admitted, that resizing 
is broken. But I do remember some discussions about using different 
model to Carl's choosen one. And btw - is 'max-size requirement still 
there?

resizing has not changed yet. it's pretty isolated so we can choose 
to fix that if Carl doesn't get to fixing it. no real show stopper 
yet, other than it's annoying to look at.

screenshots: not really anything interesting. it's the same as before, 
only I'm working on how to error handle reactors. some reactors, 
I think, should be handled in a more friendly way than currently 
(simply crash).

So we can start using R3-GUI and expect minor changes to use and 
implimentation?


I thought there was going to be some major changes yet to come and 
present functionality might change significantly...

we change one thing at a time.

So if I follow the new docs i'm pretty safe?

last I read them a couple of days ago there were some inaccuracies 
compared to Carl's version, so I don't know if he's doing any of 
his own changes.

but general concepts like actors, reactors, faces, styles, etc. shouldn't 
change. it's smaller details that are a little different, like function 
names.

recycle/ballast 50000
screen: system/view/screen-gob
system/view/event-port: open event://
font1: make system/standard/font [size: 20]
fire: [
	line-width 0.5 pen black fill-pen white line-pattern white 
	text vectorial 0x70 [font font1 bold "F I R E !!!"]
]

insert strokes: skip find fire 'line-pattern 2 rand: [0 0 1 1 2 3 
3 4 4 5]
img: make image! xy: 100x100

show append screen gob: make gob! [offset: xy size: xy image: img]

forever [
	change img copy/part skip img 0x1 100x76
	change strokes random rand
	draw img fire
	effect img [blur difference 2.5.10]
	wait 0.03
	show gob
]

better with:

effect img [blur img difference 2.5.10]

Steeve - nice effects :-)

i optimized it a litlle bit (removed the "change copy/part image" 
that eats memory)

and the flames are dancing :)

recycle/ballast 50000
screen: system/view/screen-gob
system/view/event-port: open event://
font1: make system/standard/font [size: 20]
insert strokes: skip fire: [
	image img (first random [1x-2 0x-2 1x-2 0x-2 -1x-2])
	line-width 0.5 pen red fill-pen white line-pattern black 
	text vectorial 0x40 [font font1 bold "F I R E !!!"]
] 'line-pattern 2 rand: [0 1 1 1 2 5 ]
img: make image! xy: 100x70

show append screen gob: make gob! [offset: xy size: xy image: img]
forever [
	change strokes random rand
	draw img fire
	effect img [difference 3.5.8 blur img]
	wait 0.05 show gob
]

Script: "Untitled" Version: none Date: none

** Script error: skip does not allow word! for its offset argument
** Where: catch either either applier do
** Near: catch/quit either var [[do/next data var]] [data]

insert strokes: skip find fire: [

hmm, quite fast :-)

yes 'im glad, perfs are good

i even slowed down the timer

and it takes some 3-6% CPU here ...

yep, here too

ah, now 50% :-)

varying

I wonder what would be needed for transition effects, as e.g. PowerPoint 
has ... to slide away screen or its elements in various ways. There 
is some basic effect -fly-out - in recent R3 gui demo, but dunno 
if it is interchangeable

e.g. try following in R2: http://xidys.com/rebol/presentation.r

only need to be coded :)

instead of just hard coding those, I'd rather build a scheme to perform 
automatic shape/size/color/transparency transitions.

those gui elements are live and functioning ...

I agree with Henrik ...

as you can see at the end of presentation.r script, Jeff Kreiss built 
a nice dialect. Reminds me of Scala script ...

i try something like this in my VID, i have a scheme named animator 
(basically a collection of animations, plugable in styles)

the burden is that most of animations need to hack the draw block 
of the gob on which they apply

so i created a function CAPTURE

What do you mean by "my VID"? :-)

I use it like that:
>> capture gob [pen stroke-color]
which means:

if the gob has a [pen color!] in its draw block, then the var stroke-color 
is intiated with it.

And the [pen stroke-color] replace the initial sequence or if not 
found, add it in the draw block.

my VID ?, i do my own research on VID. I don't intend to use the 
standard one in my own apps, sorry for that.

That's OK, no? Noone said there should be just only one GUI. But 
we could exchange some ideas, of course if it is not fundamentally 
different :-)

see the idea:

gob: make gob! [
	draw: [
		line-width 3
		pen red
		text [...]
		...
	]
]

stroke-color: none
capture gob [pen stroke-color]

print [gob/draw stroke-color]
[
    line-width 3 pen stroke-color
    text [...]
    ...
]
255.0.0

will it work with more complex gobs? so far, VID3.4 uses one gob 
per style, but maybe for some styles, multiple gob aproach (along 
with dialect like Gab's make-gobs) might be used ...

I use this to merge effects with existing draw blocks (it's called 
by the constructor of each animation).

It's up to you to merge the effects with inner gobs if the style 
got many.


The VID, I build, doesn't matter if the style contains several gobs.
Thanks to my propagation model of events.

I use the same idea than R2, events are propagated from inner gobs 
to outer gobs, so that i can have only one reactor on a parent gob 
(the container) which trigger the same actions on all its inner gobs.

It's the thing i don't like in the current VID and it's why styles 
can't deal easly with several children gobs to my mind.