Sorry, forgot to link to GLIPS Graffiti: http://glipssvgeditor.sourceforge.net/
Jake On Fri, Oct 10, 2008 at 9:33 AM, Jake Beard <[EMAIL PROTECTED]> wrote: > 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: [email protected] >> 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/
