World: r3wp

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.

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.

Steeve, above script does not run for me using latest R3...

Script error: skip does not allow word! for its offset argument

first version works though..

insert strokes: skip find fire: [

Bingo! Nice!

A small question: I am reading the GUI documentation. Are concepts 
exposed going to change since the resuming of developments ?

Some parts in the docs don't match the source that we have here, 
but I'm not sure if it's something that Carl is doing or if they 
are mistakes left in.

As far as we can, we'd like to keep the concepts as they are, while 
probably introducing 1-2 new concepts. There are just some areas 
that need better working parts, like resizing.

I get an error with this example from the docs:

button "View" view [button "Close" close]

** GUI ERROR: Cannot parse the GUI dialect at: button Close close
** Throw error: halted by user or script

view: ["Change the contents of a panel." what [word!] where [word!]] 
[
		; Allow it to open a new window too ??
		switch-panel get where get what none
	]

Seems you can't pass a block to the 'view reactor.

it seems that reactors are supposed to be self documenting, but I'm 
not sure how to get the help information out...

Any progress on R3-GUI side? Has the work already started? :-)

I've been working on docs (a dialect for image annotation in docs, 
actually) for a program, so not much here. Some things are actually 
very difficult to do in DRAW. I could use a pure alpha overwrite 
mode. I've posted a report in the AGG group about a bug in TRANSLATE.


I might add something to specs, which I've been working with as part 
of writing docs: A way to use a layer to provide editing tools, i.e. 
box handles, rotate handles, swipe selections, moving and resizing, 
like you have in many graphics editors. I think this can be done 
in a generic way and would make it easy to build any kind of graphics 
or GUI editor.


This is not something that we want to add now, but it's nice to think 
into the design, so that it's simple to do later (and to remove, 
when Carl announces that he doesn't like it).

So this is for group (us) to consider, and for Cyphre to implement? 
:-)

TRANSLATE is for Cyphre to consider. The rest is me and everyone 
else.

But generally said - we are still waiting for Carl to move View to 
command! interface and releasing the sources? Carl almost finished 
GUI docs, which is nice, but I still miss one doc - his pov on - 
where to go next - still some concept descriptions missing, e.g. 
his plan for layers, etc.

Yes, some things are a little odd in this respect: the docs state 
functions that don't exist, such as MAKE-REACTORS, but he hasn't 
said anything about whether he's modifying the sources. Once the 
View host gets released, many more people can work on their things.


For us, there are plenty of things to work on: Begin the implementation 
of a proper table, better dialogs and more styles.