Re: [svg-developers] Preferred editing environments SVG et al
Jake wrote:
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 just tried something that worked, part of the way. I took a simple SVG file
(shown below) having simple script and
just wrapped it in html tag with xhtml namespace. It rendered in Aptana's
Firefox emulator.
But any mouseclick event throws an exception:
Exception: evt is not defined File: [...]/.tmp_simpleDrag.xhtml.49888~ Line: 1
Column: 0
I added xmlns:ev=http://www.w3.org/2001/xml-events; to the svg thinking that
that might help, but it didn't. The file works just fine in IE, FF, Opera,
Safari, Chrome, but not in Aptana as served as faux xhtml.
Any ideas?
thanks
David
?xml version=1.0 encoding=utf-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
body
svg xmlns=http://www.w3.org/2000/svg; width=100%
xmlns:xlink=http://www.w3.org/1999/xlink;
xmlns:ev=http://www.w3.org/2001/xml-events;
script![CDATA[
xmlns=http://www.w3.org/2000/svg;
xlink=http://www.w3.org/1999/xlink;
document.documentElement.setAttribute(onclick,remove(evt))
function remove(evt){
if (evt.target.nodeName==rect) add(evt)
else document.documentElement.removeChild(evt.target)
}
function add(evt){
var C=document.createElementNS(xmlns,circle)
C.setAttributeNS(null, r, 50)
C.setAttributeNS(null, cx, evt.clientX)
C.setAttributeNS(null, cy, evt.clientY)
document.documentElement.appendChild(C)
}
//]]
/script
rect width=100% height=100% fill=white/
circle r=50/
text font-size=12 x=50 y=20 Click something to remove it/text
text font-size=12 x=50 y=80 Click nothing to add something/text
/svg
/body/html
[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/
Re: [svg-developers] Preferred editing environments SVG et al
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
Re: [svg-developers] Preferred editing environments SVG et al
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
Re: [svg-developers] Preferred editing environments SVG et al
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: 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
[svg-developers] Preferred editing environments SVG et al
Hi folks, I've been trying, rather unsystematically, to explore various options for SVG editing/authoring. See http://www.w3.org/Graphics/SVG/IG/wiki/Authoring_tools_and_editors for a list of things known or suspected of being relevant to the task (both software packages and features relevant to the evaluation). The ideal tool is, of course, free, easy to learn and use, powerful, standards compliant, extensible, cross-platform etc. etc. Thus far I've determined that KompoZer (a lovely little package originating with Daniel Glazman and colleagues) does not yet support SVG I'm interested in confirmation or denial of my experiments that suggest that: [all statements below involve huge disclaimers] 1. Aptana Studio (associated with the Open Ajax Alliance) does not yet support SVG. I installed a recent version and it seems to refuse to recognize the file type or to display any graphics. I agree with Jake that Aptana Studio is well worth paying attention to. 2. Nvu (from which KompoZer is descended) also does not support SVG 3. PsPad (despite having a plugin that is ostensibly for SVG) does not support SVG 4. Safari/webkit Web Inspector is rather buggy for SVG in the Windows environment and seems not to support SVG editing and saving 5. Eclipse has a Batik related SVG viewer (Cameron what do you use?). Eclipse seems a bit like an elephant gun. 6. Firebug seems to be more of a debugging environment than an authoring environment. (For example I can't seem to create a new blank page in it). 7. WebDwarf seems not to have a direct coding mode in which you can directly modify source code. 8. oXygen is huge, and hence, rather overwhelming, but seems to have good SVG support. the last claim I understand to be false but I cannot prove it false: 9. HTML-Kit has no way to preview SVG files [all statements above involve huge disclaimers] I would be quite happy to be set straight about any of the above observations. In some cases I spent less than an hour fiddling with the package to see if I could get it to play futbol so I well may have missed something obvious to the enthusiasts. Can anyone comment first-hand on experiences with Dragonfly (I've played with it a bit but haven't figured it out well enough to be able to modify code yet) notepad++, textpad, Seamonkey or Safari/webkit web inspector for Mac? I'm likely to make pointers to any comments people leave on this subject, so smile for the camera! Again if there are other programs that belong on the list, I'd like to know about them as well. Am interested in gathering informed reviews of any or all of these. cheers, David [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/
Re: [svg-developers] Preferred editing environments SVG et al
A couple of comments: 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. Graphical Design B. Client-Side Scripting - If you're targeting the browser environment, you will almost certainly be required to write all of your UI logic in JavaScript. This may involve leveraging certain AJAX toolkits. C. Server-Side Programming - In PHP, Ruby, Python. There may be a database component involved as well. D. Client-Side Debugging E. Server-Side Debugging For A, the best free tool, in my opinion, is Inkscape. If need to hand-tune your XML after saving your work from Inkscape, then you either need a plain text or specialized XML editor. Vim has always been enough for me. oXygen is probably going to be overkill for most things. For B, client-side scripting, once again, I prefer Vim and command-line tools, but I started with Aptana, and it is definitely the most impressive, complete environment at the moment for writing serious applications in JavaScript. It may be the case that Eclipse is holding Aptana back from being very good at working with SVG. It was my understanding that, at the moment, Eclipse was poorly-suited for working with SVG, because there is no SVG renderer that integrates with SWT (Batik uses Java2D). On the other hand, SWT does have a Gecko renderer integrated into it, so I wonder if it might not be worth another look to see what would happen if you were to save a compound XHTML-SVG document with the SVG content inlined inside, and open it up in Eclipse's Gecko-based HTML previewer. If you make sure it has a .xhtml extension, then the MIME type should no longer give you any trouble, and it would be interesting to see if it would actually render. For D, debugging, I've had great success with Firebug, but only for compound XHTML-SVG documents. For plain old SVG documents, Firebug doesn't work at all, unfortunately. In general, this hasn't been a limitation, because if you're going to leverage most AJAX toolkits, you need the HTML context (this has at least been true for mootools and dojo, in my experience, and seems to be true for prototype as well, as I think I saw noted in some of the source code of the Lively Kernel). I have also had success with Opera Dragonfly on compound documents, but have not tested it on regular SVG documents. Aptana has a debugger, but it is literally just using Firebug on the backend (it actually needs to open up Firefox to debug), and is less featurful than simply using Firebug (no command-line in Eclipse). For C and E, take your pick of environments... It's interesting to note that Aptana seems to be buying up all of the good Eclipse-based environments for dynamic languages, including RadRails, and, recently, Pydev, my favorite environment for Python development. Now if it would just integrate them in a meaningful way, and be able to provide me with a Gecko-based preview of the results, all right in the Eclipse environment, then that would really be something Jake On Thu, Oct 9, 2008 at 6:12 PM, ddailey [EMAIL PROTECTED] wrote: Hi folks, I've been trying, rather unsystematically, to explore various options for SVG editing/authoring. See http://www.w3.org/Graphics/SVG/IG/wiki/Authoring_tools_and_editors for a list of things known or suspected of being relevant to the task (both software packages and features relevant to the evaluation). The ideal tool is, of course, free, easy to learn and use, powerful, standards compliant, extensible, cross-platform etc. etc. Thus far I've determined that KompoZer (a lovely little package originating with Daniel Glazman and colleagues) does not yet support SVG I'm interested in confirmation or denial of my experiments that suggest that: [all statements below involve huge disclaimers] 1. Aptana Studio (associated with the Open Ajax Alliance) does not yet support SVG. I installed a recent version and it seems to refuse to recognize the file type or to display any graphics. I agree with Jake that Aptana Studio is well worth paying attention to. 2. Nvu (from which KompoZer is descended) also does not support SVG 3. PsPad (despite having a plugin that is ostensibly for SVG) does not support SVG 4. Safari/webkit Web Inspector is rather buggy for SVG in the Windows environment and seems not to support SVG editing and saving 5. Eclipse has a Batik related SVG viewer (Cameron what do you use?). Eclipse seems a bit like an elephant gun. 6. Firebug seems to be more of a debugging environment than an authoring environment. (For example I can't seem to create a new blank page in it). 7. WebDwarf seems not to have a direct coding mode in which you can directly modify source code. 8. oXygen is huge, and hence, rather overwhelming, but seems to have
RE: [svg-developers] Preferred editing environments SVG et al
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] - 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/
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] - 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/
