AltME groups: search

AGG/Cairo/Skia is the only solution acceptable for me, unless proven 
otherwise.

Certainly no more a nonsense argument than that Enlightenment would 
be unacceptable compared to AGG, Cairo and Skia

is that plain C, or C++? Btw - how does Cyphre wrap AGG, if AGG is 
said to be strict C++? Does he have to write any wrapper in C first? 
(He said he has AGG in a form of DLL for R2)

Yep. :-) The REBOL AGG engine is implemented in C++. You basically 
have to write the draw dialect interpreter in C++ to be able to use 
AGG or any of the other C++ engines

Magnusso - Cyphre said, that he has new framework in mind, kind of 
View like, just a bit abstracted, so that it could use different 
backend systems (Cairo, AGG, Skia, Fog ....). But - not sure his 
target is Red. But maybe we convince him to port it for some fee 
:-)

REBOL/View also depends on an external graphics library, namely AGG. 
The difference is currently in the level of integration. Once the 
Red/System compiler linker becomes more capable, for example when 
it can produce libraries or object files, it may be possible to integrate 
graphics libraries as tightly with Red as AGG is integrated with 
REBOL

Kaj, hate to nitpick, but REBOL/View's AGG library is statically 
linked, so it's not really "external". Static linking for Red would 
be nice.

Robert - it is just that talking to Cyphre, he was eventually interested 
in a "port", which would be more of a new implementation, supporting 
more advanced stuff in the backend (as switching targets, hw acceleration, 
etc.), and doing it in his free time the initial guess was 12 months. 
Such product would be surely cool, but it seems to me, that it could 
be just the second stage. 


In first stage, I would prefer having windowing/events plus AGG ported 
(still fast enough for many things, I don't understand the obsession 
about the speec, well, apart from devices lacking float support, 
here, AGG would be really slow). Such step could be done in 2-3 months 
of work? Then ppl could start port R3 GUI to it ....

Well, I don't necessarily like big solutions/libraries. Of course 
it will make sense, if they are already a part of the toolchain, 
e.g. GTK being part of every linux distro, Android, etc. , ditto 
Cairo. So far I could see complaints about AGG not being accelerated, 
and what irritates me about such claims is - we never ever utilised 
full advantage of AGG, yet we complain. And then we are going to 
use crap like Cairo, just becau HW is going to help us. I would rather 
use smaller AGG instead of several times bigger Cairo lib, and orientiate 
myself on HW, which has floating point unit. Before we finish, even 
our small devices are going all to have FPU imo ...

Gregg - I will see how Red evolves in regards to events etc., so 
that later on I can have someone look, how difficult would it be 
to port View from R3 to Red/System. AGG is just platform agnostic 
(I think), then there's a windowing system, maybe not so difficult, 
but Doc might have some other plans for events, etc.

Here is first *alpha* of Rebol3 with graphics on Android: http://development.saphirion.com/experimental/r3-droid-view.apk

Current features:
- AGG based compositor
- Basic windowing support
- Working DRAW dialect
- Very basic input event handling (DOWN, UP, MOVE, CLOSE events)

- "Menu" button now sends "escape" to the interpreter so loops etc. 
can be easily interrupted

- "Back" button closes opened windows, if no window is open it quits 
interpreter

- Embedded simple "demo game", just type DEMO in the console and 
have fun


Note this release is very early alpha so expect unstable situations 
or even crashes. Feel free to report bugs or any other feedback.


This gets us one step closer to be able to create Android apps with 
Rebol. Simple, small, fast. :-)

assuming you are using faces for the text, in AGG its a bit more 
work.

No, it was just his long term idea, to abstract the engine, so that 
it can use various backends - AGG, Cairo, etc, and provide platform 
acceleration, where available. Unfortunatelly, that was just an idea 
on his side, no real project. There is nothing wrong with View engine 
itself, apart from some bugs in core, which make it look unfinished. 
That would not happen with Red, as all sources and hence debugging 
is possible ...

I thought you found AGG too slow on your phone?

Kaj - I do remember View 1.0 alpha with CID (predecessor to VID) 
on a Pentium 75, 130 - ran "acceptable". Cell phones have limited 
UI needs imo, I doubt AGG will be slow. Of course some heavy operations 
might drag some juice from the battery, as it is not accelerated. 
We now need to find the ways of how to get Cyphre's idea becoming 
a reality ...

Kaj, yes, but the changes I plan will allow you to relatively easily 
use different renderer component. Even in current host-kit I would 
just replace the agg renderer with something more suitable for slow 
or not sufficiently equipped  ARM cpus but the "framework base" of 
the sytem would remain same.

Pekr, my experiment showed AGG on ARM without FPU was way slower 
than the native implementation of Android Canvas engine...mainly 
because the Canvas uses integer based rasterizer etc.

Also If you need pixel-precise results in your app you can still 
use the Agg for making hi-quality output etc.

Well, without R3 core being compiled to droid, there's no chance 
to get R3 running there, no? So your tests involved pure AGG test, 
with no relation to REBOL?

AdrianS: re OpenGL. I see multiple ways here:

-try to HW accelerate the AGG graphics engine (currently used in 
R3) : I did some experiments which looks interesting. But the more 
you 'accelerate it' the more compatibility problems you get on different 
HW so it's about wighting the pros/cons.

-build completely OpenGL based engine (big task, brings lot of crossplatform/HW 
issues)


Otherwise it would be great if the current R3 graphics codebase is 
reviewed and some parts made more modular so different graphics engines/libraries 
are easier to plug-in. That should be not so hard work to do.

For those interested in the "alpha-channel change":

Here is the branch with first round of related code changes to the 
image! and image codecs: https://github.com/cyphre/r3/commit/472c106a0f177ead82a6f29be1ae98b4cd33b9ad


Note: This code doesn't contain any graphics related changes...just 
the image! datatype + image codecs so you can MAKE images and load 
BMP, GIF, PNG and JPG files. But it should be enough to test the 
change.

(I have this code already intergated with changed AGG graphics and 
it works well but I haven't published it as this part is not compatible 
with the 'official' git source at the moment.)

Note2: the code was not tested on big-endian systems so it is possible 
there can be some quirks. Use at your own risk and let me know about 
any problems.


The RGBA tuples on IMAGE! now work so if the fourth(alpha) value 
is not defined it is assumed the RGB tuple is opaque (ie. alpha = 
255) so 0.0.0 = 0.0.0.255 etc. This way color values in old code 
that doesn't explicitly define alpha values are still compatible.


If you are interested, try to compile and test a bit. Let me know 
if you see any issues. Thanks.

NickA: during my private talks to Cyphre, he told me that if he would 
aproach the View engine nowadays, he would abstract it a bit, so 
that it could use various rendering backends - AGG, Cairo, so that 
where platform permits, it could be HW accelerated. But - such project 
would take some time, and Cyphre would have to be sponsored, in order 
to be able to do the work. I think, that it could be even written 
in a way, so that both R3 and Red benefit. But who knows ...


As for Red - no party is willing to port View engine, yet :-) Doc 
wants to aproach it other way - to use something like VID dialect, 
but final toolkit used would be the native platform one. Kaj did 
some example with Red/System + GTK, if I understand it correctly. 
I still think that even for Red, something like small View  engine 
would be benefical, e.g. for embedded work, where non traditional 
graphics is not a problem.


Dunno, how difficult would it be to get View sources adapted to Red/System. 
Red is missing on timers, events, etc., so maybe later, so that it 
can be naturally plugged in to its architecture ...

with higher resolution displays, comes higher performant CPUs/GPUs. 
Tegra 4 announced, 4core A15 1.5 GHz + 1 A8 Core, 72 GPU cores .... 
I still think, that we did not utilise full power of AGG yet. Gee, 
View 1.x ran on my Pentium 75 machine ....

With HRD comes higher performant GPUs but I'm not sure how CPU scales. 
Look at Adobe, they are almost dropping support for classic display 
list (rendered on CPU) and forcing everybody to use their Stage3D 
which uses GPU. It's not easy move as there is almost no tooling 
yet, but it's a must. CPU is not able to process so many pixels with 
the new screens (with high frame rate). I don't say we should drop 
AGG support, just that there must come GPU support using OpenGL/DirectX 
and let the AGG to do high quality rendering of assets.

I don't say you should use OpenGL for DRAW. There is no drawing api 
in Stage3D as well. I was proposing to use AGG to draw to bitmap 
with the best possible quality and let the HW do what it's made for.. 
to move pixels around. Bo understands it. That's actually how are 
modern apps made to have 60fps. To make animations just in AGG will 
not work (and honestly never worked). But maybe I'm too involved 
in animations and for many people would be enough to have static 
content. But that is not for future.

Bo, I even tried to HW accelerate the AGG renderer code so it is 
completely using OpenGL...works well and you can use draw directly 
inside the OpenGL context mixed with 2d surfaces or 3d objects...lot 
of fun. But still , lot of stuff is still computed on CPU that way. 
Nevertheless its still better that fully SW based renderer.

The best solution for nowadays gfx HW would be to rewrite most of 
the AGG code for GPU using shaders. That would be state-of-the-art 
2d engine for future. But also pretty big task ;)

Bo, I think if we don't make drastic changes to the GOB mechanism 
we should be safe when building anything on top of the GOB datatype. 
The gob! is in fact abstraction layer between the "VIew engine" and 
any "GUI framework" written in REBOL.
So as take this example:

We have now R3GUI framework which runs quite well on the current 
View engine (although this engine was build in 2 weeks during the 
very early R3 alpha work so it's kind of Q&D prototype ;))
(BTW should I mention the R3GUI is much better than R2 VID?)

Anyway, the R3GUI works on current View engine. When I tried to change 
the engine so it uses OpenGL accelerated AGG the R3GUI still worked 
without any problem (except visual bugs caused by incomplete OpenGL 
code implementation of the new prototype).

SO from that example you can see the "View engine" and "GUI framework" 
are two independent things and can be developed or even exchanged 
separately.

Version > 1.2.48
 does it mean "version upper than 1.2.48" ?
It mean AGG inside so!! It's alpha, with many bugs arround.

Try with a tupple of 4 value with max alpha value :
pen 0.0.0.255

Yes, but should work with AGG ones

I used succesfully such arrays of floats as argument in my interface 
to AGG...this is no problem IMO

Cyphre do you have documentation on AGG anywhere?

in the current way to handle you need to be very sharp to can interact 
with it from rebol and that why Cyphre you have all my admiration 
for your quick made AGG external exploitation script ...

I presume AGG makes it easier to distort text for a visual Captcha 
...

in front of vi of windows notepad for example it's oriented  Make 
doc Pro (Robert Version) and the look and feel is not has nice that 
if I could include in it the whole widget AGG based set of Cyphre

I like your idea of combining AGG text in there.  I want my console 
to be better than the console in a Peugot car.

hehehe yes but it's a hard stuff to do actually many ppl are interrested 
in maling widgets based or exploiting AGG capability but we are all 
work un linked so the think are not to be release tomorrow ;)

Kaj, why AGG nor Cairo were found as insufficient for Syllable purposes? 
IIRC it is Cairo, which will be used by Mozilla platform or even 
OS-X to render, no?

I'm interested in that, too. :-) What I know is that Arno is making 
deep changes to the video driver framework to add backbuffering in 
the memory of the video cards. We think about AGG as a crossplatform 
rendering library, but Arno is considering the few simple drawing 
functions in Syllable. Things like line drawing are passed directly 
to the video drivers, and if a driver supports 2D acceleration, the 
draw is done in hardware by the video card. In our new framework, 
these drawing operations need to be able to work directly in the 
memory of the video card when necessary. It makes sense that crossplatform 
libraries are not suitable for this deep integration

Kaj, does Syllable use any particular library for gfx? I don't remember 
what you said. am I right you considered even agg, but then your 
gfx guru decided to go his own way?

It is amazing how we Open Source can divide people. There is gray 
all over the place and this is not a black and white issue. I think 
this is not about the armies of developers, or the quality, but about 
the ability to move fwd and construct on the disclosure of code. 
For as much bad applications there are in Open Source, there are 
good ones, OpenBSD, GCC, Postgress, and the one Rebol incorporated 
AGG.

Thats the reason some projects flourish and others die, or lag behind. 
AGG vs Cairo.

So, it has been for me extremely rare to find it educationally useful. 
However, there are the gems, and things like AGG are shining examples. 
I wil grant you that. (But then, I do not try to understand AGG, 
I just accept it for a masterpiece that it is.)

no, I don't have x-windows powered linux here ... I was just curious, 
as there were some features not supported iirc? but maybe I am confused 
because of os-x version ... well, agg does not use fonts, but dunno 
if true or not ...

not sure what dependencies are there ..... there might be some library 
missing, as happened with my Command due to AGG

Guys, please be patient ;) I'll post DRAW change summary in AGG group 
very soon.

Louis I think that depends on how many people work on widgets set 
and what capabilities and imaginativ they are  :) (Cyphre style with 
AGG are trully a good research way )

like transparente popupmenu layer for menu bars in cyphre style sets 
using AGG

The "problem" with either approach (sub-face / draw) is that RT have 
two technologies (TMD / AGG) that could dramatically impact any implementation 
... but we have no idea when these will be available. :(

Asley I know that it. But that's not beacause RT is working on it 
too that we can't work on it right now with yet existent technologies 
and try to figure out how to do it with the limited capabilities 
(bacause we don't have aaccess to entire VM source code) we have. 
In futur once we yet trully have a working solution and VM will have 
officiallly the new technology AGG we could help Carl on TDM  by 
apporting our RTE/IR (ritch text editor input renderer) code to him. 
it's a base of search for us but it means to be one implicitly for 
Carl If we want to save his time and focus it on the important things 
we have maybe to take in charge some od research work  ;)

Graham some indulgence please menu in rebgui are very alpha stage 
vefor sunday I don"t even know  what could be the result of having 
it to rebogui and if it was workable with older non AGG capable rebol/view 
;)

Global Event System: looks like 'menu has to use it, and I don't 
know if we have a real alternative. One thing I've added to 0.1.8 
is a 'keep function that lets you specify what widgets you wish to 
use and sets to none everything not used by those widgets ... so 
if more complex widgets require global events then so be it.


Contributed code: I prefer simple code (that may need to be enhanced) 
over complex code (that may have to be pruned).


Multi-tasking: The RebGUI engine is 90% where it needs to be so I'm 
spending most of my time on widget integration at the moment.


View 2.0: We have to work with what we have, although I have made 
a concession to the future [AGG] with regards to RebGUI's use of 
draw in preference to image + effects.


Dialectise RebGUI: It would be relatively easy to make the specification 
more VID-like by having each attribute specified with a distinct 
datatype (and moving duplicate datatypes such as an 'offset pair 
to a keyword such as 'at) but you pay a big price in code complexity 
and efficiency; and I'm not convinced that inferred attributes ("this 
is a 3-part tuple so it must be a color, while this is a 4-part tuple 
so it must be a span") make code legibility and maintenance any easier.


None of this is to say I can't be convinced otherwise, this is why 
RebGUI is still ALPHA. ;)

Chris noticed that under AGG things are a bit blurred since we use 
draw commands.

Check and Radio-Group? AGG looks better for these than the pre-AGG 
pixelated look. The lines have more definition and weight IMHO. Can't 
see any difference with Tab-Panel and Button.

nb. Shadwolf: as our Arrow style was pre-AGG, glyph rendering does 
not take advantage of the newer draw commands.  Therefore, it may 
be possible to reduce or eliminate calculations used in 'compose-arrow.

OT: the problem with AGG AA on smaller glyphs (not just arrow) is 
that it tends to have an adverse effect on glyph weight.  'course 
it beats bitmaps when it comes to scaling, but even pre-AA Draw gave 
more precise control -- hence the deterioration of the Arrow glyph 
post-AGG.  Illustrated here: http://www.ross-gill.com/r/chevron-test.png

Chris: i think that your example above turned out being a bug in 
gamma handling in earlier versions of view/agg. i'm not sure if it's 
the same on the latest version (especially if you adjust gamma properly 
for your monitor - the default should be ok for crt monitors i think)

Well  In fact I figured out there was lot of problems with my first 
 port of the arrow and arw widgets made by Chris & Gregg  initialy 
for VID/AGG. So now it's mutch better I solve all existing problems 
in my first implementation.  I made lot  of code cleaning. I let 
implementation samples in commentary and comments maide by initial 
authors ;). Can be found here: http://shadwolf.Free.fr/arrow-RebGUI-port.r

tab-panel: make face [
		color:	none
		pane:	[]
		l-arw: none 
		r-arw: none
		dir-buttons: false
		feel:	make default-feel [
			redraw: function [face act pos] [test-size test-wid] [
				if act = 'show [face/pane/1/size: face/size - 0x20
; 					
; 				 	test-wid: face/pane/1
; 		    		test-size: test-wid/size/x
; 					if greater? test-size face/size/x  [
; 						either not dir-buttons [
; 				 			dir-buttons: true
; 		    				insert tail face/pane face/l-arw: make arrow [
; 	        					size: 20x20
; 		    					offset: as-pair (face/size/x - 40) 0
; 		    					data: 'left
; 		    					action: [print "you clicked left" ]
; 	     					] do face/l-arw/init
; 		    				insert tail face/pane face/r-arw: make arrow [
; 	        					size: 20x20
; 		    					offset: as-pair (face/size/x - 20) 0 
; 		    					action: [print "you clicked right" ]
; 		    					data: 'right
; 	     					] do face/r-arw/init
; 	 					][	
; 	 						face/r-arw/offset: as-pair (face/size/x - 20) 0 
; 	 						face/l-arw/offset: as-pair (face/size/x - 40) 0 
; 	 					]
; 	     			]

; 			    print "la liste des bouttn est plus grande  que ce que l'on 
voit!!!" 
		    	]
			]
		]
		
		init:	has [tab-offset last-tab] [
			;	create main display area
			insert pane make face [ offset: 0x20 edge: default-edge]
			;	add tabs
			tab-offset: 0x0

   insert tail pane make face [ offset: 0x0 pane: [] color: none ]
			container: last pane

   insert container/pane make face [ offset: 0x0 pane: [] color: none]
			foreach [title spec] data [
				insert tail container/pane/1/pane make face [
					offset:	tab-offset
					size:	1x20
					pane:	[]
					text:	title
					effect:	reduce ['round edge-color 5 'draw copy []]
					resize:	none
					font:	make default-font [align: 'center valign: 'bottom]
					para:	default-para
					feel:	make default-feel [
						over: func [face act pos] [
							either act [

        insert face/effect/draw compose [	; compose required for AGG betas
									pen over-color
									line 3x1 (as-pair face/size/x - 4 1)
									line 2x2 (as-pair face/size/x - 3 2)
									line 1x3 (as-pair face/size/x - 2 3)
								]
								show face
							][

        if face/parent-face/parent-face/parent-face/pane/1/pane <> face/data 
        [	; clear unless selected
									clear face/effect/draw
									show face
								]
							]
						]
						engage: function [face act event] [pf old-face] [
							if event/type = 'down [
								pf: face/parent-face
								pf3: pf/parent-face/parent-face

        if pf3/pane/1/pane = face/data [return]	; has a new tab been selected?
								clear face/effect/draw
								old-face: pick pf/pane pf3/data			; find previous tab
								old-face/resize: pf3/size				; remember last size
								old-face/size: old-face/size - 0x1		; deflag old
								clear old-face/effect/draw
								face/size: face/size + 0x1				; flag new
								face/feel/over face true 0x0
								pf3/data: index? find pf/pane face		; set new pane#
								pf3/pane/1/pane: face/data				; init tab panel
								if pf3/size <> face/resize [				; recursive resize
									span-resize pf3/pane/1 pf3/size - face/resize
									face/resize: pf3/size
								]
								show pf3
							]
						]
					]
				]
				last-tab: last container/pane/1/pane

    last-tab/size/x: 10 + first size-text last-tab	; set tab title width

    display/layout "" spec last-tab					; generate tab spec into tab 
    pane
				last-tab/data: last-tab/pane					; swap pane into data
				last-tab/pane: none								; clear pane
				last-tab/resize: size							; original panel size

    tab-offset/x: tab-offset/x + last-tab/size/x	; set offset for next 
    tab title
			]
			print "size et countainer a la con !!"
			probe size/x
			container/size: as-pair size/x 20
			probe container/size/x
			container/pane/1/size: container/size

   container/pane/1/pane/1/size: container/pane/1/pane/1/size + 0x1	; 
   flag 1st tab
			data: 1								; set pane#
			pane/1/pane: container/pane/1/pane/1/data			; init tab panel

   container/pane/1/pane/1/feel/over container/pane/1/pane/1 true 0x0	; 
   flag first as active
		]
	]

REBOL [
	Title:		"SVG Demo"
	Owner:		"Ashley G. Trüter"
	Version:	0.0.1
	Date:		21-Jun-2005
	Purpose:	"Loads and displays a resizeable SVG file."
	History: {
		0.0.1	Initial release
	}
	Notes: {
		Tested on very simple SVG icons
		Only a few basic styles / attributes / commands supported

  Does not handle sizes in units other than pixels (e.g. pt, in, cm, 
  mm, etc)

  SVG path has an optional close command, "z" ... AGG shape equivalent 
  auto-closes

  load-svg function needs to be totally refactored / optimized ... 
  *sample only*
	}
]

;	The following commands are available for path data:
;
;		M = moveto
;		L = lineto
;		H = horizontal lineto
;		V = vertical lineto
;		C = curveto
;		S = smooth curveto
;		Q = quadratic Belzier curve
;		T = smooth quadratic Belzier curveto
;		A = elliptical Arc
;		Z = closepath

;print: none	; comment out this line to enable debug messages

load-svg: function [svg-file [file! string!] size [pair!]] [

 id defs x y to-color to-byte draw-blk append-style svg-size scale-x 
 scale-y
][
	xml: either string? svg-file [parse-xml svg-file] [

  unless %.svg = suffix? svg-file [to error! "File has an invalid suffix!"]
		parse-xml read svg-file
	]

 unless xml/3/1/1 = "svg" [to error! "Could not find SVG header!"]

 ;unless find ["id" "xmlns"] xml/3/1/2/1 [to error! "Could not find 
 ID header!"]

 ;unless xml/3/1/3/1/1 = "defs" [to error! "Could not find DEFS header!"]

	id: xml/3/1/2
	defs: xml/3/1/3


	;
	;	--- Parse SVG id
	;

	svg-size: either find ["32pt" "48pt" "72pt"] select id "width" [
		switch select id "width" [
			"72pt"	[120x120]
			"48pt"	[80x80]
			"32pt"	[60x60]
		]
	][

  as-pair to integer! any [select id "width" "100"] to integer! any 
  [select id "height" "100"]
	]

	x: to integer! any [select id "x" "0"]
	y: to integer! any [select id "y" "0"]

	scale-x: size/x / svg-size/x
	scale-y: size/y / svg-size/y

	;
	;	--- Helper functions
	;


 to-color: func [s [string!]] [	; converts a string in the form "#FFFFFF" 
 to a 4-byte tuple
		to tuple! load rejoin ["#{" next s "00}"]
	]


 to-byte: func [s [string!]] [	; converts a string with a value 0-1 
 to an inverted byte
		255 - to integer! 255 * to decimal! s
	]

	;
	;	--- Parse SVG defs
	;

	draw-blk: copy []

	append-style: function [
		command [string!] blk [block!]
	][
		x xy pen-color fill-color line-width mode size radius shape
		closed? matrix transf-command
	][
		xy: 0x0
		size: 0x0
		line-width: 1
		matrice: make block! []
		radius: none
		transf-command: none
		
		
		foreach [attr val] blk [
			switch attr [
				"transform" [print "tranform have been found" 
						;probe val halt 
						val: parse val "(),"
						transf-command: first val
						probe transf-command
						switch transf-command [
							"matrix" [ 
								foreach word val [
									if not find word "matrix"
									[ 
										insert tail matrice to-decimal word
									]
								]
							
							]
						]
				]
				"style" [
					foreach [attr val] parse val ":;" [
						switch/default attr [
						
							"font-size" [ ]
							"stroke" [
								switch/default first val [
									#"#" [pen-color: to-color val]
									#"n" [pen-color: none]
								][
									print ["Unknown stroke:" val]
								]
							]
							"stroke-width" [line-width: to decimal! val]
							"fill" [
								fill-color: switch/default first val [
									#"#" [to-color val]
									#"n" [none]
								][
									print ["Unknown fill value:" val]
									none
								]
							]
							"fill-rule" [
								mode: switch/default val [
									"evenodd"	['even-odd]
								][
									print ["Unknown fill-rule value:" val]
									none
								]
							]

       "stroke-opacity" [pen-color: any [pen-color 0.0.0.0] pen-color/4: 
       to-byte val]

       "fill-opacity" [fill-color: any [fill-color 0.0.0.0] fill-color/4: 
       to-byte val]
							"stroke-linejoin" [
								insert tail draw-blk switch/default val [
									"miter"		[compose [line-join miter]]
									"round"		[compose [line-join round]]
									"bevel"		[compose [line-join bevel]]
								][
									print ["Unknown stroke-linejoin value:" val]
									none
								]
							]
							"stroke-linecap" [
								insert tail draw-blk 'line-cap
								insert tail draw-blk to word! val
							]
						][
							print ["Unknown style:" attr]
						]
					]
				]
				"x"			[xy/x: scale-x * val]
				"y"			[xy/y: scale-y * val]
				"width"		[size/x: scale-x * val]
				"height"	[size/y: scale-y * val]
				"rx"		[print "rx"]
				"ry"		[radius: to decimal! val]
				"d"	[
					shape: copy []
					x: none
					closed?: false
					foreach token load val [
						switch/default token [
							M	[insert tail shape 'move]
							C	[insert tail shape 'curve]
							L	[insert tail shape 'line]
							z	[closed?: true]
						][

       unless number? token [print ["Unknown path command:" token]]

       either x [insert tail shape as-pair x scale-y * token x: none] [x: 
       scale-x * token]
						]
					]
				]
			]
		]
		insert tail draw-blk compose [
			pen (pen-color)
			fill-pen (fill-color)
			fill-rule (mode)
			line-width (line-width * min scale-x scale-y)
		]
		switch command [
			"rect" [
				insert tail draw-blk compose [box (xy) (xy + size)]
				if radius [insert tail draw-blk radius]
			]
			"path" [
				unless closed? [print "Path closed"]
				either transf-command <> none  [
					switch transf-command [

      "matrix" [insert tail draw-blk compose/only [ (to-word transf-command) 
      (matrice) shape (shape) reset-matrix]]
					]
				][
					insert tail draw-blk compose/only [shape (shape)]
			 	]
				]

   "g" [ print "Write here how to handle G insertion to Draw block" 

    insert tail draw-blk probe compose/only [reset-matrix (to-word transf-command) 
    (matrice)]
				
				]
			]
	]	
  
	probe defs
	foreach blk defs [
		switch first blk [
			"rect"	[append-style first blk second blk]
			"path"	[append-style first blk second blk]
			"g"		[
						print "key word" probe first blk  
						print "matrix and style in G" probe second blk  
						append-style first blk second blk 
						;print "what to draw in G" probe third blk
						foreach blk2 third blk [
							probe blk2
							switch first blk2[ 
								"path" [append-style first blk2 second blk2]
							]
						]
					]
		]
	]
	
	
probe draw-blk
	draw-blk
]

view make face [
	offset:	100x100
	size:	200x200
	action:	request-file/filter/only "*.svg"
	text:	rejoin ["SVG Demo [" last split-path action "]"]
	data:	read action
	color:	white
	effect:	compose/only [draw (load-svg data size)]
	edge: font: para: none
	feel: make feel [
		detect: func [face event] [
			if event/type = 'resize [
				insert clear face/effect/draw load-svg face/data face/size
				show face
			]
			if event/type = 'close [quit]
		]
	]
	options: [resize]
]

REBOL [
	Title:		"SVG Demo"
	Owner:		"Ashley G. Trüter"
	Version:	0.0.1
	Date:		21-Jun-2005
	Purpose:	"Loads and displays a resizeable SVG file."
	History: {
		0.0.1	Initial release
	}
	Notes: {
		Tested on very simple SVG icons
		Only a few basic styles / attributes / commands supported

  Does not handle sizes in units other than pixels (e.g. pt, in, cm, 
  mm, etc)

  SVG path has an optional close command, "z" ... AGG shape equivalent 
  auto-closes

  load-svg function needs to be totally refactored / optimized ... 
  *sample only*
	}
]

;	The following commands are available for path data:
;
;		M = moveto
;		L = lineto
;		H = horizontal lineto
;		V = vertical lineto
;		C = curveto
;		S = smooth curveto
;		Q = quadratic Belzier curve
;		T = smooth quadratic Belzier curveto
;		A = elliptical Arc
;		Z = closepath

;print: none	; comment out this line to enable debug messages

load-svg: function [svg-file [file! string!] size [pair!]] [

 id defs x y to-color to-byte draw-blk append-style svg-size scale-x 
 scale-y
][
	xml: either string? svg-file [parse-xml svg-file] [

  unless %.svg = suffix? svg-file [to error! "File has an invalid suffix!"]
		parse-xml read svg-file
	]

 unless xml/3/1/1 = "svg" [to error! "Could not find SVG header!"]

 ;unless find ["id" "xmlns"] xml/3/1/2/1 [to error! "Could not find 
 ID header!"]

 ;unless xml/3/1/3/1/1 = "defs" [to error! "Could not find DEFS header!"]

	id: xml/3/1/2
	defs: xml/3/1/3


	;
	;	--- Parse SVG id
	;

	svg-size: either find ["32pt" "48pt" "72pt"] select id "width" [
		switch select id "width" [
			"72pt"	[120x120]
			"48pt"	[80x80]
			"32pt"	[60x60]
		]
	][

  as-pair to integer! any [select id "width" "100"] to integer! any 
  [select id "height" "100"]
	]

	x: to integer! any [select id "x" "0"]
	y: to integer! any [select id "y" "0"]

	scale-x: size/x / svg-size/x
	scale-y: size/y / svg-size/y

	;
	;	--- Helper functions
	;


 to-color: func [s [string!]] [	; converts a string in the form "#FFFFFF" 
 to a 4-byte tuple
		to tuple! load rejoin ["#{" next s "00}"]
	]


 to-byte: func [s [string!]] [	; converts a string with a value 0-1 
 to an inverted byte
		255 - to integer! 255 * to decimal! s
	]

	;
	;	--- Parse SVG defs
	;

	draw-blk: copy []

	append-style: function [
		command [string!] blk [block!]
	][
		x xy pen-color fill-color line-width mode size radius shape
		closed? matrix transf-command
	][
		xy: 0x0
		size: 0x0
		line-width: 1
		matrice: make block! []
		radius: none
		transf-command: none
		
		
		foreach [attr val] blk [
			switch attr [
				"transform" [print "tranform have been found" 
						;probe val halt 
						val: parse val "(),"
						transf-command: first val
						probe transf-command
						switch transf-command [
							"matrix" [ 
								foreach word val [
									if not find word "matrix"
									[ 
										insert tail matrice to-decimal word
									]
								]
							
							]
						]
				]
				"style" [
					foreach [attr val] parse val ":;" [
						switch/default attr [
						
							"font-size" [ ]
							"stroke" [
								switch/default first val [
									#"#" [pen-color: to-color val]
									#"n" [pen-color: none]
								][
									print ["Unknown stroke:" val]
								]
							]
							"stroke-width" [line-width: to decimal! val]
							"fill" [
								fill-color: switch/default first val [
									#"#" [to-color val]
									#"n" [none]
								][
									print ["Unknown fill value:" val]
									none
								]
							]
							"fill-rule" [
								mode: switch/default val [
									"evenodd"	['even-odd]
								][
									print ["Unknown fill-rule value:" val]
									none
								]
							]

       "stroke-opacity" [pen-color: any [pen-color 0.0.0.0] pen-color/4: 
       to-byte val]

       "fill-opacity" [fill-color: any [fill-color 0.0.0.0] fill-color/4: 
       to-byte val]
							"stroke-linejoin" [
								insert tail draw-blk switch/default val [
									"miter"		[compose [line-join miter]]
									"round"		[compose [line-join round]]
									"bevel"		[compose [line-join bevel]]
								][
									print ["Unknown stroke-linejoin value:" val]
									none
								]
							]
							"stroke-linecap" [
								insert tail draw-blk 'line-cap
								insert tail draw-blk to word! val
							]
						][
							print ["Unknown style:" attr]
						]
					]
				]
				"x"			[xy/x: scale-x * val]
				"y"			[xy/y: scale-y * val]
				"width"		[size/x: scale-x * val]
				"height"	[size/y: scale-y * val]
				"rx"		[print "rx"]
				"ry"		[radius: to decimal! val]
				"d"	[
					shape: copy []
					x: none
					closed?: false
					foreach token load val [
						switch/default token [
							M	[insert tail shape 'move]
							C	[insert tail shape 'curve]
							S   [insert tail shape 'curv]
							L	[insert tail shape 'line]
							Q   [insert tail shape 'qcurve]
							T   [insert tail shape 'qcurv]
							z	[closed?: true]
							H   [insert tail shape 'hline]
							V   [insert tail shape 'vline]
							A   [insert tail shape 'arc]
						][

       unless number? token [print ["Unknown path command:" token]]

       either x [insert tail shape as-pair x scale-y * token x: none] [x: 
       scale-x * token]
						]
					]
				]
			]
		]
		insert tail draw-blk compose [
			pen (pen-color)
			fill-pen (fill-color)
			fill-rule (mode)
			line-width (line-width * min scale-x scale-y)
		]
		switch command [
			"rect" [
				insert tail draw-blk compose [box (xy) (xy + size)]
				if radius [insert tail draw-blk radius]
			]
			"path" [
				unless closed? [print "Path closed"]
				either transf-command <> none  [
					switch transf-command [

      "matrix" [insert tail draw-blk compose/only [ (to-word transf-command) 
      (matrice) shape (shape) reset-matrix]]
					]
				][
					insert tail draw-blk compose/only [shape (shape)]
			 	]
				]

   "g" [ print "Write here how to handle G insertion to Draw block" 

    insert tail draw-blk probe compose/only [reset-matrix (to-word transf-command) 
    (matrice)]
				
				]
			]
	]	
  
	probe defs
	foreach blk defs [
		switch first blk [
			"rect"	[append-style first blk second blk]
			"path"	[append-style first blk second blk]
			"g"		[
						print "key word" probe first blk  
						print "matrix and style in G" probe second blk  
						append-style first blk second blk 
						;print "what to draw in G" probe third blk
						foreach blk2 third blk [
							probe blk2
							switch first blk2[ 
								"path" [append-style first blk2 second blk2]
							]
						]
					]
		]
	]
	
	
probe draw-blk
	draw-blk
]

view make face [
	offset:	100x100
	size:	200x200
	action:	request-file/filter/only "*.svg"
	text:	rejoin ["SVG Demo [" last split-path action "]"]
	data:	read action
	color:	white
	effect:	compose/only [draw (load-svg data size)]
	edge: font: para: none
	feel: make feel [
		detect: func [face event] [
			if event/type = 'resize [
				insert clear face/effect/draw load-svg face/data face/size
				show face
			]
			if event/type = 'close [quit]
		]
	]
	options: [resize]
]

REBOL [
	Title:		"SVG Demo"
	Owner:		"Ashley G. Trüter"
	Version:	0.0.1
	Date:		21-Jun-2005
	Purpose:	"Loads and displays a resizeable SVG file."
	History: {
		0.0.1	Initial release
	}
	Notes: {
		Tested on very simple SVG icons
		Only a few basic styles / attributes / commands supported

  Does not handle sizes in units other than pixels (e.g. pt, in, cm, 
  mm, etc)

  SVG path has an optional close command, "z" ... AGG shape equivalent 
  auto-closes

  load-svg function needs to be totally refactored / optimized ... 
  *sample only*
	}
]

;	The following commands are available for path data:
;
;		M = moveto
;		L = lineto
;		H = horizontal lineto
;		V = vertical lineto
;		C = curveto
;		S = smooth curveto
;		Q = quadratic Belzier curve
;		T = smooth quadratic Belzier curveto
;		A = elliptical Arc
;		Z = closepath

;print: none	; comment out this line to enable debug messages

load-svg: function [svg-file [file! string!] size [pair!]] [

 id defs x y to-color to-byte draw-blk append-style svg-size scale-x 
 scale-y
][
	xml: either string? svg-file [parse-xml svg-file] [

  unless %.svg = suffix? svg-file [to error! "File has an invalid suffix!"]
		parse-xml read svg-file
	]

 unless xml/3/1/1 = "svg" [to error! "Could not find SVG header!"]

 ;unless find ["id" "xmlns"] xml/3/1/2/1 [to error! "Could not find 
 ID header!"]

 ;unless xml/3/1/3/1/1 = "defs" [to error! "Could not find DEFS header!"]

	id: xml/3/1/2
	defs: xml/3/1/3


	;
	;	--- Parse SVG id
	;

	svg-size: either find ["32pt" "48pt" "72pt"] select id "width" [
		switch select id "width" [
			"72pt"	[120x120]
			"48pt"	[80x80]
			"32pt"	[60x60]
		]
	][

  as-pair to integer! any [select id "width" "100"] to integer! any 
  [select id "height" "100"]
	]

	x: to integer! any [select id "x" "0"]
	y: to integer! any [select id "y" "0"]

	scale-x: size/x / svg-size/x
	scale-y: size/y / svg-size/y

	;
	;	--- Helper functions
	;


 to-color: func [s [string!]] [	; converts a string in the form "#FFFFFF" 
 to a 4-byte tuple
		to tuple! load rejoin ["#{" next s "00}"]
	]


 to-byte: func [s [string!]] [	; converts a string with a value 0-1 
 to an inverted byte
		255 - to integer! 255 * to decimal! s
	]

	;
	;	--- Parse SVG defs
	;

	draw-blk: copy []

	append-style: function [
		command [string!] blk [block!]
	][
		x xy pen-color fill-color line-width mode size radius shape
		closed? matrix transf-command
	][
		xy: 0x0
		size: 0x0
		line-width: 1
		matrice: make block! []
		radius: none
		transf-command: none
		
		
		foreach [attr val] blk [
			switch attr [
				"transform" [print "tranform have been found" 
						;probe val halt 
						val: parse val "(),"
						transf-command: first val
						probe transf-command
						switch transf-command [
							"matrix" [ 
								foreach word val [
									if not find word "matrix"
									[ 
										insert tail matrice to-decimal word
									]
								]
							
							]
						]
				]
				"style" [
					foreach [attr val] parse val ":;" [
						switch/default attr [
						
							"font-size" [ ]
							"stroke" [
								switch/default first val [
									#"#" [pen-color: to-color val]
									#"n" [pen-color: none]
								][
									print ["Unknown stroke:" val]
								]
							]
							"stroke-width" [line-width: to decimal! val]
							"fill" [
								fill-color: switch/default first val [
									#"#" [to-color val]
									#"n" [none]
								][
									print ["Unknown fill value:" val]
									none
								]
							]
							"fill-rule" [
								mode: switch/default val [
									"evenodd"	['even-odd]
								][
									print ["Unknown fill-rule value:" val]
									none
								]
							]

       "stroke-opacity" [pen-color: any [pen-color 0.0.0.0] pen-color/4: 
       to-byte val]

       "fill-opacity" [fill-color: any [fill-color 0.0.0.0] fill-color/4: 
       to-byte val]
							"stroke-linejoin" [
								insert tail draw-blk switch/default val [
									"miter"		[compose [line-join miter]]
									"round"		[compose [line-join round]]
									"bevel"		[compose [line-join bevel]]
								][
									print ["Unknown stroke-linejoin value:" val]
									none
								]
							]
							"stroke-linecap" [
								insert tail draw-blk 'line-cap
								insert tail draw-blk to word! val
							]
						][
							print ["Unknown style:" attr]
						]
					]
				]
				"x"			[xy/x: scale-x * val]
				"y"			[xy/y: scale-y * val]
				"width"		[size/x: scale-x * val]
				"height"	[size/y: scale-y * val]
				"rx"		[print "rx"]
				"ry"		[radius: to decimal! val]
				"d"	[
					shape: copy []
					x: none
					closed?: false
					if all [x not number? token] [

          insert tail shape x * either token = 'V [scale-y][scale-x]
  						    x: none
					]
					foreach token load val [
						switch/default token [
							M	[insert tail shape 'move]
							C	[insert tail shape 'curve]
							S   [insert tail shape 'curv]
							L	[insert tail shape 'line]
							Q   [insert tail shape 'qcurve]
							T   [insert tail shape 'qcurv]
							z	[closed?: true]
							H   [insert tail shape 'hline]
							V   [insert tail shape 'vline]
							A   [insert tail shape 'arc]
						][

       unless number? token [print ["Unknown path command:" token]]

       either x [insert tail shape as-pair x scale-y * token x: none] [x: 
       scale-x * token]
						]
					]
				]
			]
		]
		insert tail draw-blk compose [
			pen (pen-color)
			fill-pen (fill-color)
			fill-rule (mode)
			line-width (line-width * min scale-x scale-y)
		]
		switch command [
			"rect" [
				insert tail draw-blk compose [box (xy) (xy + size)]
				if radius [insert tail draw-blk radius]
			]
			"path" [
				unless closed? [print "Path closed"]
				either transf-command <> none  [
					switch transf-command [

      "matrix" [insert tail draw-blk compose/only [ (to-word transf-command) 
      (matrice) shape (shape) reset-matrix]]
					]
				][
					insert tail draw-blk compose/only [shape (shape)]
			 	]
				]

   "g" [ print "Write here how to handle G insertion to Draw block" 

    insert tail draw-blk probe compose/only [reset-matrix (to-word transf-command) 
    (matrice)]
				
				]
			]
	]	
  
	probe defs
	foreach blk defs [
		switch first blk [
			"rect"	[append-style first blk second blk]
			"path"	[append-style first blk second blk]
			"g"		[
						print "key word" probe first blk  
						print "matrix and style in G" probe second blk  
						append-style first blk second blk 
						;print "what to draw in G" probe third blk
						foreach blk2 third blk [
							probe blk2
							switch first blk2[ 
								"path" [append-style first blk2 second blk2]
							]
						]
					]
		]
	]
	
	
probe draw-blk
	draw-blk
]

view make face [
	offset:	100x100
	size:	200x200
	action:	request-file/filter/only "*.svg"
	text:	rejoin ["SVG Demo [" last split-path action "]"]
	data:	read action
	color:	white
	effect:	compose/only [draw (load-svg data size)]
	edge: font: para: none
	feel: make feel [
		detect: func [face event] [
			if event/type = 'resize [
				insert clear face/effect/draw load-svg face/data face/size
				show face
			]
			if event/type = 'close [quit]
		]
	]
	options: [resize]
]

Thanks for taking this up and running with it guys, you're making 
great progress (far better than I could have). Feel free to take 
ownership of the code and refactor it as needed.

Two minor improvements are:

	unless closed? [insert tail shape reduce ['move 0x0]]

which is Gabriele's fix to the shape close problem, and:

	feel: make feel [
		redraw: func [face act pos] [

   if act = 'draw [insert clear face/effect/draw load-svg face/data 
   face/size]
		]
	]


which cleans the sample feel code up a bit. I'd also remove "VID" 
from the title of this group as DRAW AGG is tied to View. ;)

yes it' quite a nightmare for a AGG newbie as I'm ...

for example the implementation of the LIneargradient I dont have 
any idea about how to translate it to AGG

I'm working hard on the translation of the linearGradient informations 
from SVG files   to AGG

if you wants to write the "in" AGG/draw code that is based on my 
rebol linear gradient list there is the code and a sample file from 
InkScape

I read most of the documentation but then make the link to AGG data 
structure is rather difficult

Good progress! If you change:

	"stroke-width" [line-width: to decimal! val]

to

	"stroke-width" [line-width: to-unit val]


then it'll run all your sample SVG icon files as well. Wish I knew 
the answers to your AGG questions, but like you I'm waiting on more 
documentation / examples.

but what I need are high level information and formation on draw 
agg and this I know very little people that can respond in this point 
 :)

For ppl interrested in  SVG rendering engine. My  tonight work  and 
 test on the engine   is resumed in the AGG topic. To resume before 
matrix bug as causing bad scale and bad position.  Now we have good 
position but still bad scale  i post screen cap samples and we can 
see that the evolution is good  betwin View 1.3.1 and 1.3.2

transform problem are on their way to be solve gradient too by cyphre 
and  Carl those  two things are the most blockant problems until 
they are not completly solved we can't expect to have a full working 
SVG rendering engine  -> most of SVG  imagines use transform effects 
and gradients this means    that if we want to get a pretty good 
and reliable SVG engine we have to fixe those two issue. SVR rendering 
engine is a good and hudge test upon AGG integration to REBOL/View 
and it allows us to embetter it !!! 


Once we get a fully working engine with basic human understandable 
algorithm i will start the  optimisation process using  parse (but 
to be franck i don't  know how parse will react in front svg row 
data or how will be the time to dev this parse based SVG engine ... 
 in all cases I think the actual engine have teached me a lot arrounf 
the SVG to AGG adaptation process so i hope the translation to parse 
and parse/rules will not be too hard and too long)

well last thing i can say is that SVG rendering  engine is very high 
on my task  list ( task number one) i worked on the adding of some 
other new drawing primitive  (image rect, circles). I will continue 
to  work on the close support of all SVG datas that can have a meaning 
in AGG context. SVG rendering engine is  a   2   weeks of work only!!! 
... until i fall on the gradient and transforms problems so this 
ensure us advancing on this project will be very fast once we solve 
bugs in REBOL/View related to AGG (wich is in progress actually)

ty ashley   ^^ time i wasn't giving notice of my progress but mainly 
because Gradeint and transform problem where dependent on AGG an 
not on my  script.

now let's convince Carl, that as AGG was good choice for vectors, 
we should find another library for sound. Maybe fmod?

the question is - AGG for vectors, is one of two best free libraries 
- Cairo and AGG ... so - how is fmod quality wise? Is there any better, 
smaller library to have?

Hi .... with recent Rebcode releases, we can see that internally 
new Core is marked as 2.7 and View is marked as 1.4 Is it just working 
"title" or will those products be marked as that? And if so, can 
we know, what other changes will go for 1.4 View release target? 
Will there be any AGG fixes/additions (to support SVG RebGUI progress), 
or even VID changes? I still think, that VID is missing few fine 
styles as tab, group-box, better list as was introduced on IOS Developer's 
server, (eventually tree, menu), to allow novices to start using 
VID/View more productively. Any chance RT can tell us, what is the 
plan for 1.4 release?

Q: What does the world on Nov-15-2005 look like?


A: Our main goal is to get REBOL into the hands of more users, not 
just programmers and techies.... by the millions over time.  By doing 
that, we create a market for not only handy free REBOL apps, but 
also for commercial apps and entire businesses that are related to 
REBOL.



Q: Given that  window transparency is OS specific, will there be 
a dialect that covers both Windows, Linux and 40+ other OS?  In other 
words, does RT plan on continued support of so many languages, or 
are we entering a new era of specific OS support?


A: Our plan is to make that a window option that is part of the face/options 
for a window.  If an OS does not support this mode, then the option 
will be ignored, but the application will still be fully functional.



Q: I hope it is still valid that cooperation with RT is possible. 
I mean - last few weeks I play with some Win32 functions (thanks 
to Gregg) and I would like we would have proper app behavior in multi-monitor/multi-desktop 
environments .... so I wonder if any SIGs will be created, some ppl 
will be invited to participate, comment etc., or if RT is gonna cook 
it all themselves?


A: Yes, there are many such special interest projects currently going 
on. (Most of them are occurring via private projects in AltME and 
IOS.)  These days 90% of REBOL changes are done in cooperation with 
the REBOL community.



Q: Hi .... with recent Rebcode releases, we can see that internally 
new Core is marked as 2.7 and View is marked as 1.4 Is it just working 
"title" or will those products be marked as that? And if so, can 
we know, what other changes will go for 1.4 View release target? 
Will there be any AGG fixes/additions (to support SVG RebGUI progress), 
or even VID changes? I still think, that VID is missing few fine 
styles as tab, group-box, better list as was introduced on IOS Developer's 
server, (eventually tree, menu), to allow novices to start using 
VID/View more productively. Any chance RT can tell us, what is the 
plan for 1.4 release?


A: Regarding 2.7 and 1.4 question: we change the revision numbers 
(the second number) whenever there is a major change in REBOL that 
may be unstable.  The /core 2.7 kernel (that is in /view 1.4 as well) 
adds new datatypes to REBOL, and they are the first datatypes added 
in several years, so we consider this to be a major change, and marked 
it that way.
Yes, we do plan to be making a few AGG fixes very soon.

Oh, and regarding VID: we plan to be making very big changes there. 
More to come soon.


Q: Could you add struct! support to /Core?

I keep on having situations that would be made much easier by struct! 
when I don't need libraries. For instance, conversions from external 
binary data encodings to internal REBOL values, say for file formats, 
network protocols and so on. Now rebcode has added other forms of 
strong typing like the type-specific opcodes and the vectors. Having 
structs with their constrained field types, their specific data layouts, 
would be a perfect match for the low level operations of rebcode. 
They would be helpful later when implementing your own data types 
as well.


A: On structs: yes, we will enable this feature on core, but it should 
only be used for lower level code.  Objects are more powerful.


Q: Could you add an APPLY opcode to rebcode?

    apply: ["Apply function or path to arguments, save result" word! 
    word! | path! block!]

In rebcode:
    apply x f [arg1 arg2 ...]
Is equivalent to this in REBOL:
    x: do f arg1 arg2 ...


The advantage to doing function calls this way is that the arity 
of the opcode is fixed, even if the arity of the function called 
can't be known ahead of time. The value assigned to the function 
word could be either a function or a path, or for efficiency you 
could have a seperate opcode APPLYP for path values (I'd prefer just 
one opcode for generality but it's your call).


A: I'm not sure what is meant by the path for it. You mean for refinements?
That may actually slow down the apply interface.

Gabriele - could you please pass my latest comments/links to Carl? 
I looked into Io slide-show and found they do use libevent library. 
I posted links into TechNews group. There is interesting reading 
in-there, also hidden is some links - liboop and The C10K problem 
..... Maybe we will find another libraries for further rebol improvements, 
like Cyphre did find agg.

Is the rebol.dll included with the sdk2.62 the same as the viewdll 
that is the plugin ?

If so, what are the magic numbers to use to make it act as the plugin 
?  ( the old plugin doesn't have AGG ).
Thanks.

Ruby community to clone Rebol/View (AGG) - http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/35c2f61d29e94550/28b32a50948920ba

If the build add the Rails framework to the  Ruby/AGG backend. I 
think Ruby will have another big market gain.

Cyphre did find some link to beta Ruby/AGG release, which one note 
of author, stating something like "Download beta release, but this 
is unexpectadly slow :-(" ... which could mean there is still a long 
way to go for them, and we can have REBOL 4.0 by that time ...

graham - my reference was not to Ruby/AGG, which apparently can be 
a good product, but to statements like "rails .... even faster than 
rebol" - whish sounds, from someone who is interested in languages 
so much, like a plain nonsense, comparing language to framework ...

why negative. It is because you read is as a negative. My reaction 
translates to - if PS is good thing to have, then let's have it, 
but then it would be good to have native rebol ps viewer (in AGG) 
or there will be a trouble, if such a thing is dependant upon external 
viewer. And that is my experience here and I can guarantee you, that 
in terms of our big corp it would be a problem. But enough, do what 
you think is best ...

In fact - my question could be just simplified - how do we do print 
preview without GhostView or other PS viewer tools? If that is "somehow" 
possible, then it is only good. That is why I referred to the need 
of AGG based preview, to actually save third app usage - a PS viewer.

AGG DRAW is pure vector gfx

Bugs found in Firefox with Cyphre demo: 

- starts with no sound (the music started when I opened a parallel 
session with Opera, in Opera the sound is ok)

- seems there are some problems with AGG: no rotating Carl Head, 
some flash with gears, no "rebol rulez" in the sky... (Opera is ok)

- when I close firefox the music continue for 4/5 seconds (until 
the buffer is empty ?). In Opera too.

- sometimes the plugin disappear if I refresh the page. I have to 
close the browser. In Opera too.


WIn2000, nVidia GeForce4 MX 440, Firefox 1.5.0.3, Opera 9.0 beta 
build 8393

I have seen a dozen applications used by companies.  The Neilsen 
Media company (famous for their Neilson Report of TV) uses Flash 
for all their applications.  


They could have used Rebol, but Flash is actually better for what 
they are doing.  If Rebol had more front end, or could play back 
SWF files thorugh AGG, then we might have something.


Rebol on the other hand is better for the heavy lifting, parsing 
websites, etc.

u think about using agg directly ?

its VID based, so any current draw blocks set in the effects can 
be used.  the buttons, field, and choice use AGG for their rendering.

thanks  :-)  took a bit of tweaking to get the stuff sorted out, 
but I'm starting to get the hang of AGG.

also note that currently, its 100% AGG/

well, whole new View is 100% AGG :-) Cyphre switched compositing 
engine to that of AGG internally AFAIK

The truth is, I do not have the reflex of using liquid for most of 
my coding, still, but actuall exposure and use, is forcing me to 
value its effect on my code.  this is empiric use, not advocacy. 
 If you could see just how easy it was for me to build fully bug-free 
AGG gadgets in so little time, you'd understand.


its not about just sharing data between gadgets, its about allowing 
your code to know what's going on.

elixir, for example,  easily allocates 10 000 nodes, creates a several 
thousand line AGG script and actually manages to rebuild the whole 
AGG dialect block faster than view can redraw it.

elixir builds a 100% native AGG GUI .   EVERYTHING is built using 
liquid, event the field (control) properties and cursor management.

I also have a simple graphics package which uses AGG directly with 
liquid, so I'll use that to further show liquid ties in from end-to-end.

no VID.  just AGG  ;-)

although GLASS will use the data within AGG instead of view/faces.