Here's another: http://www.pilatinfo.org/english/svgdraw/index.htm
It's much harder to port C/C++ to JavaScript than it is to port Java to JavaScript, so starting with a Java based drawing tool, like GLIPS Graffiti, would be easier. Or, you can just start from scratch, which is what I'm doing. One artifact of my research will be a functional drawing tool, the UI behaviour of which will follow Inkscape's as closely as possible. But it's a complete rewrite -no borrowed code. I'm aiming to have something useable completed by January 1st. After that, it would be interesting to see if it can be integrated into Eclipse. Jake On Fri, Oct 10, 2008 at 6:58 AM, ddailey <[EMAIL PROTECTED]> wrote: > Jake wrote: > >>I'm quite pleased about this, as it seems to me that >>Eclipse+Aptana+PyDev/RadRails comprises an extermely flexible, >>comprehensive environment for developing SVG. > > Cool. I will try to replicate what you did with the .xhtml. That sounds > promising. > >>and if someone were to write a >>simple-but-functional SVG drawing tool in SVG and JavaScript, then >>that would probably be able to slot right into the Gecko widget, >>filling in the missing functionality. Then you'd have an all-in-one >>IDE. How cool is that? > > I know of two such projects (though it seems like I've heard of others and > every year or so I see questions from folks here that makes me think they > are creating another): > Chris Peto's http://www.resource-solutions.de/svgeditor/ > and mine http://srufaculty.sru.edu/david.dailey/svg/Polylinebest.html > > Both are open source sharable stuff (I don't remember the phrasing that > Chris uses); they both have rather different interfaces. Mine is so old > (maybe five years now) that I don't know if any of the code would be > salvageable: my javascript skills were fledgling at the time, but it does > allow editing polylines and has a bezier drawing tool and so forth. I think > someone working for a few weeks could cobble something fairly nice together. > > I've wondered if any of Inkscape could be moved in a JavaScript direction, > to create an Inkscape light running in a browser, but it might be easier to > just start from scratch. > > David > > ----- Original Message ----- > From: Jake Beard > To: svg-developers@yahoogroups.com > Sent: Thursday, October 09, 2008 11:10 PM > Subject: Re: [svg-developers] Preferred editing environments SVG et al > > FYI, I just tests Aptana with the embedded Gecko renderer on a > compound XHTML-SVG document (.xhtml extension, so the Eclipse wouldn't > get confused about the MIME type), and it totally worked. Nice little > animated SVG prototype running right there in Eclipse :-) > > I'm quite pleased about this, as it seems to me that > Eclipse+Aptana+PyDev/RadRails comprises an extermely flexible, > comprehensive environment for developing SVG. It seems to cover > everything except for the design task, but fortunately we have > Inkscape for that... and if someone were to write a > simple-but-functional SVG drawing tool in SVG and JavaScript, then > that would probably be able to slot right into the Gecko widget, > filling in the missing functionality. Then you'd have an all-in-one > IDE. How cool is that? > > Jake > > On Thu, Oct 9, 2008 at 8:54 PM, Dailey, David P. <[EMAIL PROTECTED]> > wrote: >> Jake wrote: >> >>>At the moment there is certainly no one-stop-shop IDE for SVG >>>development. It may be conceptually useful, then, to separate >>>development out into several tasks. This way, you can choose which >>>tool is most appropriate for any given task. I would propose that SVG >>>development may be separated at least into: >>>[A,B,C,D,E...] >> >> Yes a good insight and the comments you make help with the sort of >> feature-analytic approach I'm pursuing. In fact, one could consider >> Boolean >> membership in each of your categories A through E as constituting five >> more >> dimensions for evaluation (perhaps not completely orthogonal one another >> or >> to the others). Ultimately human concepts (like the concepts of "tasks") >> are >> probably neither taxonomic nor multivariate but graph-theoretic or >> geometric >> in the sense of a projective geometry or point-set topology (where >> proximities vary like soap bubbles twisted around on higher-dimensional, >> or >> higher-genus, Klein bottles and pretzels. Either a kladistic or a >> taxonomic >> approach (both of which have advantages from a navigational perspective) >> will induce certain statistical stress into our model, but I have >> generally >> chosen to evaluate along a set of more or less objective dimensions in >> hopes >> that a prospective shopper will know his or her own profile of needs >> (tasks) >> a priori. A taxonomy will certainly help those with less knowledge of >> their >> own needs steer more quickly toward happiness. I think that in the >> particular case of SVG, one's reason for boarding the boat may be >> different >> than their reasons for staying aboard, implying that the more complex >> interface provided by the feature analysis may ultimately save a bit of >> backtracking later on.* It is also an idiosyncracy of my own that I >> usually >> end up not fitting into the categories of humans that other humans make**, >> so I will probably, out of stubbornness, for wont of a better reason, >> persist with a feature analysis. A very first feature, that I still seek >> evaluation of, is whether or not those particular products do or do not >> support SVG. >> >> cheers >> David >> >> * I'm thinking of the particular case here where a person who begins as a >> script writer may later discover they really wish they had the built-in >> graphical editor that came with product Y somewhere in their coding >> environment. >> ** One of my favorite theories of personality has been this: there are two >> kinds of people: those who think there are two kinds of people and those >> who >> don't. One can actually generate an infinite class of theories of >> personality differing from one another in topological structure, but that >> rather might be considered a departure from the question at hand. >> >> [Non-text portions of this message have been removed] >> >> > > [Non-text portions of this message have been removed] > > ------------------------------------ ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ----Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
