World: r3wp

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

Normand I'm glad to see that some of the UI ideas form MDP-GUI have 
been retaked into BibleX ;à

normand normally soon we will see Menu bar and popupMenu in REBGUI 
This will allow you to improve and simplifie the UI of BiBlex ;)

So many things on the fire actually ... We need to achieve some widgets 
insertion and discuss why some widgets are not inserted to rebgui 
actually...

I'm trying to make SVG rendering widget but as you can see in sVG 
RENDERER group I have many problems in translation and until now 
I'm stuck so maybe it's the appropriate time for me to seek for the 
accomplishement of yet on cooking widgets...

Graham: End of fin year and Q2 GST.

Normand: Try the following;

display "Test" [
	a: text "Name"
	b: field
	do [c: face]
]
do-events
halt

Latest build available at: http://www.dobeash.com/files/RebGUI-032.zip


*** Unzip this file into your existing RebGUI 0.3.0 distribution. 
Requires View 1.3. ***

Highlights include:

	- New keycode handler (to assign keystrokes to actions)

 - Tab focus expanded to include button handling (see %focus-demo.r 
 for details)
	- Buttons are now image based
	- Number of password widget fixes

 - Added basic SVG support (proof of concept at this stage - shadwolf 
 is working on *real* SVG support)
	- Added icon and svg-toolbar widgets to support above
	- Large number of bug fixes

 - Bit of code refactoring (split layout logic out of display function)

ashley: dragging the cursor (mouse left/right while left button down) 
on top of a password field with hidden text, makes the cursor position 
not correspond accurately to the position of the mouse. very very 
small thing, I know, but if you want it perfect. :-)

I notice that there is no cursor in a text field now when the field 
is empty.

Good work on the focus changes.

I like the field undo option. Very nice.

There's no %images/logo.png for the tour.r script to load in the 
archive. I just grabbed one myself, but thought you might want to 
know for others.

ah, I see that is addressed if I go to the download page, rather 
than just clicking links in AltME :-)

rich text, damne! :-) How should we know, what shortcut keys belong 
to what buttons ;-)

Inconsistency between button and arrows ... buttons are hovered, 
when you move mouse over, arrows are not. What is more - they are 
flat, they don't move up and down, like button does, only background 
color changes. Shouldn't it be unified? That is imo why UI rules 
should exist first - we should decide what and how should behave 
and work towards that imo ...

I am not on WinXP right now, but small comment towards tabbing of 
button. It works. Once you move your mouse over another button, the 
original one looses its tabbing, while I think it should not .... 
well, it seems to me the action still works, but hover color is lost 
...

Any chance to get the multi-column list to work in the next release? 
So that it's possible to select, add, delete entries. How about in-cell 
editing?

mine is working the dynamic data are not affected ...

that's the only remaining point to solve and add the text edition 
too..

Yes, the list works to show stuff, but I can't select an entry and 
get a feedback into my code. Or is it possible?

Possible with text-list (see %tour.r) but not table [yet].

It works with mine too

you have a built in var in it to retrieve information

picked var is used to store in my multi column list widget the selected 
line content

so the programmer that use the listview widget have only to make 
a test on listview/picked content if none -> no line is picked (so 
for example prompt an alert to the user either make processing of 
the listview/picked content

Is there something new in the pipeline? Or has the project slowed 
down?

one of my friends would imediatelly switch to RebGUI, but not without 
more solid table/grid element ...

... simply ability to display data is essential for most apps :-) 
He tried Cyphre's grid, and although it is the most complete style 
we saw yet, it does not allow things as keyboard navigation, display 
of only selected columns without rebuilding data-block ....