Re: [Inkscape-devel] DOM SVG Canvas
The work Mental had been doing assumed C. Also I suspect serious consideration would be given to keeping it in C if that would make it easier to reuse in other apps. But we really haven't talked about it.
I favour C. Does providing a C interface compromise any C++ class wrapper for that interface? Whilst I have heard of many C++ class interfaces wrapping C libraries I have never heard of the converse. Is it totally impossible because of C++ method names?
Ian Grant wrote:
The work Mental had been doing assumed C. Also I suspect serious consideration would be given to keeping it in C if that would make it easier to reuse in other apps. But we really haven't talked about it.
I favour C. Does providing a C interface compromise any C++ class wrapper for that interface? Whilst I have heard of many C++ class interfaces wrapping C libraries I have never heard of the converse. Is it totally impossible because of C++ method names?
It would mean that using classes(structs with methods) for things like NRPoint would be out, which would be a big loss in my book - there is a lot of complex code which is remarkably simplified (and made correct) if reimplemented using vector operations.
Is it actually hard to make a C wrapper around a C++ library? I know that Qoca (a C++ library I use) has a C wrapper around its C++ innards. I suspect that it is to some extent just folk law that it is easier to wrap C in C++ than vice versa.
njh
On Tue, 2 Dec 2003, Nathan Hurst wrote:
Ian Grant wrote:
The work Mental had been doing assumed C. Also I suspect serious consideration would be given to keeping it in C if that would make it easier to reuse in other apps. But we really haven't talked about it.
I favour C. Does providing a C interface compromise any C++ class wrapper for that interface? Whilst I have heard of many C++ class interfaces wrapping C libraries I have never heard of the converse. Is it totally impossible because of C++ method names?
It would mean that using classes(structs with methods) for things like NRPoint would be out, which would be a big loss in my book - there is a lot of complex code which is remarkably simplified (and made correct) if reimplemented using vector operations.
Is it actually hard to make a C wrapper around a C++ library? I know that Qoca (a C++ library I use) has a C wrapper around its C++ innards. I suspect that it is to some extent just folk law that it is easier to wrap C in C++ than vice versa.
Well, I've had to make C wrappers around C++ code in the past (in order to link to/from FORTRAN and to plugin C++ analysis code into Excel). It certainly isn't impossible but it can be a bit of a hassle, and it requires some careful planning in laying out the API since you can't use classes, templates, etc. Sometimes if your API is going to be complex it can make more sense to do the core in C with a C++ wrapper, rather than vice versa. So, I'd guess this is why the common wisdom is to make C and wrap with C++. As far as actual linkage though, that's not impossible, just takes some crafting.
Now, I was doing that on Windows with MSVC, and things may be much different nowadays on Linux, so take that with a grain of salt.
Bryce
On Mon, 1 Dec 2003 19:48:50 -0800 (PST) Bryce Harrington <bryce@...1...> wrote:
Well, I've had to make C wrappers around C++ code in the past (in order to link to/from FORTRAN and to plugin C++ analysis code into Excel). It certainly isn't impossible but it can be a bit of a hassle, and it requires some careful planning in laying out the API since you can't use classes, templates, etc.
I was imagining the interface would be just that provided by gdome2 plus functions for rendering specified regions at specified scales. This is obviously not what Mental is planning ... I presume there are good reasons why - it's just that they elude me :-)
On Wed, 2003-12-03 at 05:32, Ian Grant wrote:
I was imagining the interface would be just that provided by gdome2 plus functions for rendering specified regions at specified scales.
This is obviously not what Mental is planning ... I presume there are good reasons why - it's just that they elude me :-)
Replacing the XML tree architecture that we inherited from Sodipodi with GDome would be a pretty major architectural change (it could substantially touch nearly every file in the tree).
I'm not, on principle, opposed to using GDome, but I don't think it would be a good fit for us as the core XML representation.
The SPRepr architecture has some very rough areas, but it is very resource-efficient and has some nice properties (it's essentially a hierarchical database, with transactions, among other things).
I think where DOM is required long-term we'd be better served by implementing DOM atop our own tree representation instead. The DOM interface, at least as specified, is indepentant of any particular implementation (less true of the non-standard C bindings, but...).
-mental
On Thu, 4 Dec 2003, MenTaLguY wrote:
On Wed, 2003-12-03 at 05:32, Ian Grant wrote:
I was imagining the interface would be just that provided by gdome2 plus functions for rendering specified regions at specified scales.
This is obviously not what Mental is planning ... I presume there are good reasons why - it's just that they elude me :-)
Replacing the XML tree architecture that we inherited from Sodipodi with GDome would be a pretty major architectural change (it could substantially touch nearly every file in the tree).
I'm not, on principle, opposed to using GDome, but I don't think it would be a good fit for us as the core XML representation.
The SPRepr architecture has some very rough areas, but it is very resource-efficient and has some nice properties (it's essentially a hierarchical database, with transactions, among other things).
I'll ditto the remarks. The repr system seems pretty solid, the one major missing piece being documentation. It's not clear what functions need to be called to do what actions. It looks like this system is kind of the heart of the application, so documenting its API would probably make work easier in a *bunch* of different areas.
I think where DOM is required long-term we'd be better served by implementing DOM atop our own tree representation instead. The DOM interface, at least as specified, is indepentant of any particular implementation (less true of the non-standard C bindings, but...).
-mental
On Thu, 04 Dec 2003 01:31:03 -0500 MenTaLguY <mental@...3...> wrote:
On Wed, 2003-12-03 at 05:32, Ian Grant wrote:
I was imagining the interface would be just that provided by gdome2 plus functions for rendering specified regions at specified scales.
This is obviously not what Mental is planning ... I presume there are good reasons why - it's just that they elude me :-)
Replacing the XML tree architecture that we inherited from Sodipodi with GDome would be a pretty major architectural change (it could substantially touch nearly every file in the tree).
Ah, this is what I did not appreciate. I had just assumed that inkscape/sodipodi used libxml, and that they would be using the libxml tree structure and therefore that gdome2 could be wedged in somehow. OK, I will shut up now until I've looked at the code. Sorry :-)
Ian Grant wrote:
Ah, this is what I did not appreciate. I had just assumed that inkscape/sodipodi used libxml, and that they would be using the libxml tree structure and therefore that gdome2 could be wedged in somehow. OK, I will shut up now until I've looked at the code. Sorry :-)
Yeah. Whatever allows the nodes to be addressable in XPath style, like from Javascript. It needs to -work- like it, but the code of course doen't have to be the same. Like if you can express a node-setting like this:
myDrawing.landscape.tree.bird.color="blue";
(named nodes are like g[@id="bird"])
By the way, if I have some free time next week, I might look into what it would take to bind Mozilla's js engine with the tree. It is extremely architecture-independent.
Bob
Nathan Hurst wrote:
It would mean that using classes(structs with methods) for things like NRPoint would be out, which would be a big loss in my book - there is a lot of complex code which is remarkably simplified (and made correct) if reimplemented using vector operations.
No it wouldn't.
:-)
It would just mean a non-C++ approach would be needed. If you have handles and methods, there are many ways to map things.
I've even seen C++ innards wrapped and exposed via TCL. A lot just comes down to the final usage and choosing a good way to get there.
Of course, choosing a poor way to get there would make things very hard.
participants (6)
-
Bob Jamison -
Bryce Harrington -
Ian Grant -
Jon A. Cruz -
MenTaLguY -
Nathan Hurst