James Crook wrote:
Hi,
Hi James,
I'm going to reply to this even though I'm the most ignorant and least qualified to discuss.
I'm one of the developers with the Audacity audio editor project. Our code keeps being pulled towards a kitchen-sink architecture where everything people might ever need gets integrated in (FTP for podcasting, play lists, MIDI-Editor, de-noising tools etc). We're trying to fight back against this trend by more and more moving to 'bridging', where we find ways to bridge to other applications that already do the job.
Inkscape is going down this road too. Planning to replace our rendering code with Cairo and our Math code with lib2geom. And we've discussed breaking our codebase up into libraries to promote reuse as well.
One direction is with XML editing. Our project file that holds the descriptions of the audio clips is an XML format. I'm thinking we should bridge to: http://xml-copy-editor.sourceforge.net/ for display/update. I like the XCE editor, it uses the very powerful Scite component.
What I'm wondering is, how tightly integrated is the built in XML editor in Inkscape? Are there a raft of services that XCE/Scite would need to support to have (the option) of bridging to an external editor? Does it even make sense to be looking in this direction, or should I be looking for smaller 'footbridges' rather than bridges with 'motorway traffic'? Any comments and feedback welcome. At the moment Audacity does not integrate any XML editor at all, but I am thinking we will need to as our project structure gets more complex, for the same reasons that Inkscape already does.
IMHO the XML editor would be a great place for us to do some reuse. We could get an XML editor that was maintained elsewhere and certainly more featureful than anything we would care to carry around in our codebase. Our users have requested better XML editing and so far we haven't been able to provide.
I'm betting that it is pretty tightly coupled right now. In Inkscape's case we aren't editing an XML document on disc; we're editing a live XML document in memory being actively used by our app. That has got to be difficult. Mental would be able to comment on how this relates to threading issues we have. Ishmal would be able to comment on the possibility of using the DOM interface that he has been working on to provide such a service. If an external XML editor could hook into a live DOM interface that we expose somehow then we could do this. (This is where my ignorance shows. :-) ) Perhaps it could even be accomplished through our extensions system.
Aaron Spike