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
changes to the files in /src that call libnr?
There weren't many such changes; I'm pretty certain the ones I did make
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
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
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
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
Actually, according to the Rearchitecturing Translation Map (what a
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