On Fri, 2004-01-02 at 10:50, Bob Jamison wrote:
So, are we done, or do I need to go through cvs history and verify the changes to the files in /src that call libnr?
There weren't many such changes; I'm pretty certain the ones I did make are correct.
If we do need those types defined again, I would put the definitions in nr-types.h. Actually, C++ style, wouln't the NR header properly be NR.h?
Maybe, but we'll be doing this incrementally.
I'm not sure what libnr's future is, exactly -- if and when we adopt Cairo for the rendering backend, most of it will go away.
Until then, I want to stick with incremental changes to it, and leave it in the top-level NR:: namespace.
However, I do not see a reason to keep different precisions of integers. Wouldn't just defining an NR integer to be a long (whatever the machine) in all cases be sufficient? It looks like the changes in the patch, and the stuff you guys are talking about, merely imply giving the data more precision.
I did converge on a single integer precision (32 bits for now) -- hence the NR::ICoord typedef.
I think that now that we are in C++, and are in the midst of cleaning up and reorganizing code, a good way to enforce a proper parameter might be to make the parameters C++ NR::-defined, not C typedefs. So, instead of NRLong, Inkscape::NR::Integer.
Well, I'm hoping to get rid of NRLong/NRShort/NRWhatever alltogether.
NR::ICoord is basically the Inkscape::NR::Integer you propose, though it is (deliberately) less general-purpose. I think types should have specific types and associated meanings.
NRLong/NRShort/etc were really just (useless) replacements for the existing gint32/int_32/etc...
Actually, according to the Rearchitecturing Translation Map (what a title), it will be Cairo eventually, anyway.
Right. In the meantime, I'm a little reluctant to make heavy changes to libnr, since we depend on it so heavily none of us completely understand it yet.
-mental