MikkelFJ wrote:

 > Of course - if it runs on the web it also runs locally.

I also had that idea; but unless many platforms work this way, you would 
have to ship a server and a browser with the app; for many apps, that's 
overkill.

BTW; what about a tiny Ruby server for local SVGUI apps? As soon as 
Batik supports ECMA script, perhaps we can find a way to "live connect" 
to Ruby actions...
(The Adobe SVG Viewer already implements postURL (which, along with 
other handy client server utilities, might be incorporated in a W3 rec))

Ruby actions
   \
    \
   Ruby server
      \
       \
       Batik
         |
         |
        SVGUI ------ user input and GUI update through ECMA script

(I know: back to ASCII art school ;) )

Nicely implemented direct Ruby bingings clearly would be most fun :)

It may well become
 > the foundation of tomorrows GUI's.

That would be great.


 > The big issues with SVG that remains are
 > 1) SVG has the infrastructure but lacks good language bindings for
 > interactive programming.

Appendix D: Java Language Binding
http://www.w3.org/TR/SVG/java.html

Appendix E: ECMAScript Language Binding
http://www.w3.org/TR/SVG/escript.html

Also:

Appendix B: SVG Document Object Model (DOM)
http://www.w3.org/TR/SVG/svgdom.html

Appendix C: IDL Definitions
http://www.w3.org/TR/SVG/idl.html


 > 2) the viewers are not quite good enough or standardized enough yet.

Some implementations could become full featured quite soon.

Tobi




-- 
Tobias Reif
http://www.pinkjuice.com/myDigitalProfile.xhtml

go_to('www.ruby-lang.org').get(ruby).play.create.have_fun
http://www.pinkjuice.com/ruby/