Hey,
Now that we're including a large part of lib2geom for LPE anyway; what else can we use it for? I'm unsure of the status of the whole library. One feature that I hear alot about when talking to people is the inset/outset function in Inkscape being "less than perfect." I think this was on the TODO for lib2geom, is it done?
Thanks, Ted
Ted Gould wrote:
Now that we're including a large part of lib2geom for LPE anyway; what else can we use it for?
It is being used for snapping (right Diederik? :-). Also I think it was planned to use it for the 3D box tool.
I'm unsure of the status of the whole library.
CC'ing to lib2geom lib2geom-devel@lists.sourceforge.net
- Johan
On Wed, 2007-11-21 at 01:06 +0100, J.B.C.Engelen@...1578... wrote:
Ted Gould wrote:
Now that we're including a large part of lib2geom for LPE anyway; what else can we use it for?
It is being used for snapping (right Diederik? :-). Also I think it was planned to use it for the 3D box tool.
Anyone know how hard it'd be to tie in the inset/outset functions to use it? Is it better than what we have (I hope so :) )?
--Ted
J.B.C.Engelen@...1578... wrote:
It is being used for snapping (right Diederik? :-))
It is indeed vary valuable for that! The intersection routines are very nice, I think Nathan has done a great job on this. These routines can be used at various places throughout Inkscape. I don't know about the other stuff though...
Diederik
On Tue, 2007-11-20 at 15:50 -0800, Ted Gould wrote:
Hey,
Now that we're including a large part of lib2geom for LPE anyway; what else can we use it for? I'm unsure of the status of the whole library. One feature that I hear alot about when talking to people is the inset/outset function in Inkscape being "less than perfect." I think this was on the TODO for lib2geom, is it done?
The pieces are there, although I think it'll take setting up Inkscape to use it to find any remaining gaps in functionality.
-mental
On Tue, 2007-11-20 at 20:23 -0500, MenTaLguY wrote:
On Tue, 2007-11-20 at 15:50 -0800, Ted Gould wrote:
Now that we're including a large part of lib2geom for LPE anyway; what else can we use it for? I'm unsure of the status of the whole library. One feature that I hear alot about when talking to people is the inset/outset function in Inkscape being "less than perfect." I think this was on the TODO for lib2geom, is it done?
The pieces are there, although I think it'll take setting up Inkscape to use it to find any remaining gaps in functionality.
So I guess what we need is a lib2geom release so that we can get it packaged and linked to correctly? Then we can start to see where that breaks?
--Ted
Perhaps superfluous but still: *we can use 2geom inside Inkscape already without problem!!!*
Ted Gould wrote:
On Tue, 2007-11-20 at 20:23 -0500, MenTaLguY wrote:
On Tue, 2007-11-20 at 15:50 -0800, Ted Gould wrote:
Now that we're including a large part of lib2geom for LPE anyway; what else can we use it for? I'm unsure of the status of
the whole library.
One feature that I hear alot about when talking to people is the inset/outset function in Inkscape being "less than perfect." I think this was on the TODO for lib2geom, is it done?
The pieces are there, although I think it'll take setting
up Inkscape
to use it to find any remaining gaps in functionality.
So I guess what we need is a lib2geom release so that we can get it packaged and linked to correctly? Then we can start to see where that breaks?
I don't think we want a release now, so we can quickly address issues that surface. I think it is best to keep 2geom inside Inkscape code for 0.46, and have a good and nice 2geom release for 0.47. This way we can profit from bleeding edge 2geom which atm is nicer than a release will be imho. I am fine by copying 2geom code to Inkscape for now :-)
(note that early on in LPE development i did have 2geom linked in as separate lib, 'release like'. It is not too much of a change)
On our wiki, we have started a help page where people can ask questions and put answers. Hopefully this will grow to a somewhat complete 2geom guide. http://wiki.inkscape.org/wiki/index.php/WorkingWith2GeomFAQ
Ciao, Johan
On Wed, 2007-11-21 at 20:32 +0100, J.B.C.Engelen@...1578... wrote:
I don't think we want a release now, so we can quickly address issues that surface. I think it is best to keep 2geom inside Inkscape code for 0.46, and have a good and nice 2geom release for 0.47. This way we can profit from bleeding edge 2geom which atm is nicer than a release will be imho. I am fine by copying 2geom code to Inkscape for now :-)
We can for development, but I'd prefer not to for release. Unless the lib2geom folks are unwilling to release it, I'd prefer to go that route.
The biggest advantage this gives us is that they can fix bugs independent of Inkscape. So, if the intersection routine turns out to be numerically unstable in a certain situation a spin of lib2geom can be done without having to do a release of Inkscape. And Inkscape users still get the benefit.
--Ted
On Wed, Nov 21, 2007 at 11:43:57AM -0800, Ted Gould wrote:
On Wed, 2007-11-21 at 20:32 +0100, J.B.C.Engelen@...1578... wrote:
I don't think we want a release now, so we can quickly address issues that surface. I think it is best to keep 2geom inside Inkscape code for 0.46, and have a good and nice 2geom release for 0.47. This way we can profit from bleeding edge 2geom which atm is nicer than a release will be imho. I am fine by copying 2geom code to Inkscape for now :-)
We can for development, but I'd prefer not to for release. Unless the lib2geom folks are unwilling to release it, I'd prefer to go that route.
The biggest advantage this gives us is that they can fix bugs independent of Inkscape. So, if the intersection routine turns out to be numerically unstable in a certain situation a spin of lib2geom can be done without having to do a release of Inkscape. And Inkscape users still get the benefit.
I definitely agree with Ted. There are several libraries copied into the tree that probably ought to be broken out where possible. Other projects like Xorg, OpenOffice, etc. demonstrate the many downsides to monolithic applications, and the benefits to both users and developers of proper modularization.
I also definitely agree that if there's bugs in lib2geom, rolling a new release of it would be much, much preferable to having to roll a new Inkscape.
Bryce
-----Original Message----- From: Bryce Harrington [mailto:bryce@...961...]
On Wed, Nov 21, 2007 at 11:43:57AM -0800, Ted Gould wrote:
On Wed, 2007-11-21 at 20:32 +0100,
J.B.C.Engelen@...1578... wrote:
I don't think we want a release now, so we can quickly address issues that surface. I think it is best to keep 2geom inside Inkscape code for 0.46, and have a good and nice 2geom
release for
0.47. This way we can profit from bleeding edge 2geom
which atm is
nicer than a release will be imho. I am fine by copying 2geom code to Inkscape for now :-)
We can for development, but I'd prefer not to for release.
Unless the
lib2geom folks are unwilling to release it, I'd prefer to
go that route.
The biggest advantage this gives us is that they can fix bugs independent of Inkscape. So, if the intersection routine
turns out to
be numerically unstable in a certain situation a spin of
lib2geom can
be done without having to do a release of Inkscape. And Inkscape users still get the benefit.
I definitely agree with Ted. There are several libraries copied into the tree that probably ought to be broken out where possible. Other projects like Xorg, OpenOffice, etc. demonstrate the many downsides to monolithic applications, and the benefits to both users and developers of proper modularization.
I also definitely agree that if there's bugs in lib2geom, rolling a new release of it would be much, much preferable to having to roll a new Inkscape.
Perhaps I thought too much from the "who is going to do it" perspective. I think you have convinced me that is it better to dynamically link 2geom. This has not been tested though, so probably needs work. Static linking was what I started out with in LPE development, but when LPE moved to trunk, we chose for having our own copy of 2geom because of frequent 2geom updates caused by progressing LPE dev. Now the situation is different. (static linking would make new lib2geom releases useless for released Inkscape right?)
However, I think there are still times when 2geom changes are so big to require some rewrite of Inkscape's 2geom-using code.
Regards, Johan
On Wed, 21 Nov 2007 22:08:31 +0100, J.B.C.Engelen@...1578... wrote:
This has not been tested though, so probably needs work. Static linking was what I started out with in LPE development, but when LPE moved to trunk, we chose for having our own copy of 2geom because of frequent 2geom updates caused by progressing LPE dev. Now the situation is different. (static linking would make new lib2geom releases useless for released Inkscape right?)
Dynamic linking wouldn't be much help either -- like many STL-style C++ libraries, a lot of stuff is inlined from headers. Minor changes to interface (or even simply implementation) can easily mean binary incompatibilities.
However, one thing which I think would be very helpful to do now is if we can disentangle Inkscape's copy of lib2geom from the Inkscape build system. That way, the 2geom tree can be an exact copy of a 2geom snapshot (rather than the manually modified copy it is now), and we have a better migration path to using an out-of-tree 2geom.
-mental
On Wed, 21 Nov 2007 11:43:57 -0800, Ted Gould <ted@...11...> wrote:
We can for development, but I'd prefer not to for release. Unless the lib2geom folks are unwilling to release it, I'd prefer to go that route.
The biggest advantage this gives us is that they can fix bugs independent of Inkscape. So, if the intersection routine turns out to be numerically unstable in a certain situation a spin of lib2geom can be done without having to do a release of Inkscape. And Inkscape users still get the benefit.
The reason we favor bundling lib2geom with Inkscape for now is that we're not willing to freeze the 2geom API yet. We can certainly do independent releases, but Inkscape wouldn't benefit without at least recompilation.
-mental
participants (5)
-
unknown＠example.com -
Bryce Harrington -
Diederik van Lierop -
MenTaLguY -
Ted Gould