World: r3wp

... so my question is rather simple - can it ever be done, using 
plain Win32 API?

IIRC Carl also planned to improve granularity of event system, introduce 
view plug-ins, but I don't know ...

hum directX  this means bye bye portability ..

I think that you need to look at where Rebol/View is going to be 
used, and decide how best to improve those areas where the market 
opportunity is greatest.  Is smooth animation that opportunity?

These are things to be added... but by a team of people.  Should 
move this discussion out of this group.

switching group? but graphcs is important to rebgui! :)

Most of us just want a decent cross platform development toolkit.

that is complete in it's widget set.

dx can be wrapped and made cross-plattform.

Even though the embedded market is important, the desktop market 
is much more important .. IMHO

I agree with that statement.

I found the proper SVG output  format for InkScape it's SVG Plain 
text (this format is lighter than the normal SVG output fomat

here is the fraisier.svg version ;)

http://shadwolf.free.fr/fraisier-plaintext.svg

we save 4ko and the format seems to be more close of the one of Sodipodi 
(witch have been used to draw the iconset gived by Ashley in svg-demo.zip)

I'm playing with ashley's svg-demo.r script code in order to understand 
it and know what are missing in it. I took as reference the blender.svg 
file because it's tiny and half rendered.  I constate that <g></g> 
block that encap transformations and transformed things is not support 
and LinearGradient is not supported too ...

How can I handle in DRAW/AGG the transform matrice ability ?

better changing to AGG groupe sorry

do %rebgui.r
display "RebGuiTest" compose/deep/only [
        label "Query" t: text 40 "" return
		a: area 100x50 "In the beginning, "
        button "Insert" [
				insert a/text "Title{}"
				; edit-text a enter

    insert tail a/text "And from a barely documented VID, a need for 
    something bare but easy to document: RebGui.  And the user saw it 
    was good."
				; edit-text a enter
				show a
        ]

do [at face/pane/3/text 10 insert tail face/pane/3/text "there was 
View 1.3.  "]
] ; End Display
do-events

How to move the cursor to inside the brackets of Title{->Here<-}.

How to enter a newline, and more generally use the function defined 
in rebgui-edit.r into the area?
** Script Error: edit-text has no value
** Where: action
** Near: edit-text a enter

More generally, how to enter a string and move the cursor after the 
insertion of it.  Thanks for an answer to this 'II am New' question 
pertaining to RebGui.

This should get you going:

display "Test" [
	a: area 100x50 "Title {}"
	do [
		rebfocus a
		system/view/caret: back system/view/caret
		show a
	]
]


The RebGUI edit-text function (and indeed the majority of the edit 
context) is designed to be used from within RebGUI widgets ... it's 
not "user-space" functionality. Manipulating text and / or focus 
is done via the standard view mechanisms (system/view/caret, focal-face, 
highlight-start & highlight-end) ... RebGUI just provides an encapsulated 
front-end to these. Depending on what sort of operations need to 
be performed (e.g. move the cursor to the Nth character), we can 
certainly add additional user-space functions (much like rebfocus), 
we just need to define what these functions are and how common their 
use would be.

I have done the set of svg icons you ask me using inskscape plain 
text svg (the lighter svg format ...) you can get it here http://shadwolf.free.fr/RebGUI-svg-icons.zip
 .It's not author marking and it's my own work so no problems with 
rights issue.

I hope you will found them reliable ...

now we have to focus on the widget SVG that can renderise them ;)

Looks good under Opera. Has the SVG renderer you and Vincent have 
been working on got to the stage where it can display these? If so, 
post a link and I'll integrate that in. The entry point will be a 
function named 'load-svg in a separate file so we don't have to worry 
about "widget clutter", and I've already added a new 'icon widget 
and updated toolbar widget which use the 'load-svg function ... so 
we should be ready to go.

actually not because we have several problems on recursion group 
interpretation on gradient effect (fill and for border line fill) 
so now we are trying to make a better engine that can be use more 
efficient ly rebol object! properties we are basing our work on xml-to-object 
function ...

SVG format is so blury that you can't match it to a predeterminate 
struture you have to do a structure analyst for each leaf of the 
the object tree then get the needed information from leaf and nodes 
then convert them to rebol then apply the draw

uh, is that because of flexibility of the SVG format, or because 
of XML deriver beurocracy?

I think that's because technologie issue (graphics libs that would 
be used to normally render SVG files to screen are different from 
AGG ) then you have plenty of possibilities SVG can be seen as a 
VID  widget tree where youonly get relevent informations but the 
structure have some recusing consept

for example the path tag that describes a shape (AGG/draw word) have 
obligatory a d field but then to handle the rendering options you 
have lot of ways to handle it

so maybe AGG is not originally designed to work with SVG? OK, we 
can integrated Cairo library then too :-)

you can see the use of a style field in the path tag that encap all 
the graphical need (internal color / gradient effect, border size 
color /gradient etc...) or this information can be exploded in as 
many field that you have description

Pekr I don't think so if you see the AGG library web site you will 
see lot of example of you to use AGG with SVG ... But there we are 
working in C++ and not in REBOL ...

so you have an XML  struture we transforme it to a REBOL Object! 
tree then this tree must be glanced and translated to have the AGG 
draw block ;)

so what you are trying to say is, that AGG itself allows easier SVG 
rendering, but our Rebol wrapper is not so flexible?

hum I don't know if we can be so drammatical and have a so drastic 
point of vue ....

It's a hard job to handle SVG structure and make our decoder able 
to decode all needed  information that's all ;)

and in AGG we have differencies in the liearGradient definition that 
what we have in SVG

ah, so the main problem here is imo still the same - XML parser. 
Building kind of "DOM". Rebol's XML parser is rather simplified after 
all. I do remember using Gavain Mckenzie's xml parser, which was 
much more usefull - it allowed for hooks during parsing and created 
rebol object too ...

for lineargradient SVG gives us a transform information (can be matrix, 
rotation,scale , skew, etc...) then we have an offset  x1 X2 y1 y2 
then we have  color informations spread method

fill-pen informations is different

a bit off topic: iTunes has a widget for rating of songs with stars 
one to five. Basically it's a widget that has 5 different states, 
depending on where you click on it. Would that be on the todo list 
for RebGUI? I'm planning to have such a thing in my next rewrite 
of my listview, I showed you some time ago.

I don't think it's planned ...

but nothing prohibes you to make a sutch widget for rebgui ;)

actually my main problem i how to build path to reach information 
into the SVG rebolien converted object tree

This topic has been quiet for a while now .. anything happening??

yess I'm hardly developping SVG renderer widget as flexible and complete 
support of the SVG file format

for the momment I have some problem to sum local and global matrix 
and to translate gradient effect

as cyphre connect once per week it's not easy for me to advance

Is there a tool to enumerate all the path to the text fields in a 
RebGui application.   Rebol is great to draw interfaces, but boy 
is it owerwhelming to find the path of those fields.  I did not find 
the way (if there is one) with Anamonitor003.   To have an idea of 
what I talk see my never finished pet at www.biblex.org.

lay: layout[text "1" text "2"]
probe lay/pane/1/text