Hi All,
I just thought that we could use a quick status check on the embedded libraries in the Inkscape repo... i.e., what we have, and what we intend to do with them. My personal preference is to get rid of as many of them as possible. Here is a list of what I think the current status is... please let me know what you think:
* cxxtest - There's a patch for building against an external copy, but it introduces a few compiler warnings and there's no OSX port of cxxtest available yet [1]. We're currently running an ancient version with no customisation... we should really bump to the most recent upstream version and wait for OSX before we can drop it. Also, there's talk of replacing this with the google test framework.
* 2geom - Tracking the possibility of building against an external copy here [2]. Last time I checked, there was a crash on startup. Perhaps it would be helpful to explicitly track the upstream revision of lib2geom that's currently embedded in trunk? Until it's packaged in distros, there's not much scope for aggressively pursuing this!
* libavoid/libcola/libvpsc - all taken from the Adaptagrams project [3]. Review needed to see what divergence exists between our copy and the upstream version. Not available in many distros.
* libcroco - tracked here [4]. All upstream changes merged. Minimisation of the diff in progress, then we can send patches upstream where possible. Available in Ubuntu, at least.
* libdepixilize - New GSOC contribution. Any plans for this to be released as a standalone package? Would be good to enable an optional external build.
* libgdl - We build against external lib when using the experimental gtk+ 3 branch. All the important patches have been accepted upstream. We'll delete our internal copy when we finally switch to gtk+ 3 builds. See bug #792115 [5]. No further action needed
* libnrtype - I believe that there was a plan to replace most/all of this with Pango [6]. Is this still the intention? Is anyone in particular coordinating things?
* libuemf - New contribution [7]: Is there a plan to push this to distros? Would be good to enable an optional external build
* livarot - Apparently huge deviation from upstream lib [8]. Not in many distros.
...and I think that's it!
AV
[1] https://bugs.launchpad.net/inkscape/+bug/1094771 [2] https://bugs.launchpad.net/inkscape/+bug/1155947 [3] http://www.adaptagrams.org/ [4] https://bugs.launchpad.net/inkscape/+bug/648246 [5] https://bugs.launchpad.net/inkscape/+bug/792115 [6] http://wiki.inkscape.org/wiki/index.php/Pangoification [7] http://sourceforge.net/projects/libuemf/ [8] http://sourceforge.net/projects/livarot/
On 17-11-2013 17:52, Alex Valavanis wrote:
Hi All,
I just thought that we could use a quick status check on the embedded libraries in the Inkscape repo... i.e., what we have, and what we intend to do with them. My personal preference is to get rid of as many of them as possible. Here is a list of what I think the current status is... please let me know what you think:
...
- 2geom - Tracking the possibility of building against an external
copy here [2]. Last time I checked, there was a crash on startup. Perhaps it would be helpful to explicitly track the upstream revision of lib2geom that's currently embedded in trunk? Until it's packaged in distros, there's not much scope for aggressively pursuing this!
I agree with removing unnecessary embedded libs. But because 2geom is still very much bleeding edge, plus it is developed by Inkscape developers, I am against removing it from our source. We depend on ToT 2geom, instead of packaged versions. For now at least.
Cheers, Johan
2013/11/17 Alex Valavanis <valavanisalex@...400...>:
- cxxtest - There's a patch for building against an external copy, but
it introduces a few compiler warnings and there's no OSX port of cxxtest available yet [1]. We're currently running an ancient version with no customisation... we should really bump to the most recent upstream version and wait for OSX before we can drop it. Also, there's talk of replacing this with the google test framework.
We could replace cxxtest with Google Test, which is much more pleasant to use from the test writer's perspective and does not require custom preprocessors.
- 2geom - Tracking the possibility of building against an external
copy here [2]. Last time I checked, there was a crash on startup. Perhaps it would be helpful to explicitly track the upstream revision of lib2geom that's currently embedded in trunk? Until it's packaged in distros, there's not much scope for aggressively pursuing this!
API-breaking changes are still the norm for 2Geom, so I don't think it can be separated any time soon.
- libnrtype - I believe that there was a plan to replace most/all of
this with Pango [6]. Is this still the intention? Is anyone in particular coordinating things?
The directory name is misleading. libnrtype is not a standalone library. It is just a bunch of classes implementing text handling in Inkscape, and it uses Pango under the hood. There is some room for improvement, but overall it is in fairly good shape and replacing this part of the code is not necessary.
- livarot - Apparently huge deviation from upstream lib [8]. Not in
many distros.
livarot must die - the sooner the better. All relevant code should be ported to 2Geom.
Regards, Krzysztof
On 17 November 2013 23:41, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
API-breaking changes are still the norm for 2Geom, so I don't think it can be separated any time soon.
I don't envisage it being split out any time soon, either, but it's fairly easy to enable use of an external 2Geom build as a development option. Could potentially be useful for 2Geom devs who want to keep a couple of different experimental builds around?
libnrtype is not a standalone library. It is just a bunch of classes implementing text handling in Inkscape, and it uses Pango under the hood. There is some room for improvement, but overall it is in fairly good shape and replacing this part of the code is not necessary.
OK, great. Perhaps we can then consider renaming the folder, and updating the "Pangoification" wiki page?
livarot must die - the sooner the better. All relevant code should be ported to 2Geom.
Any suggestions for a roadmap? Is this a nightmarish job?
AV
On 17-Nov-2013 15:41, Krzysztof Kosiński wrote:
livarot must die - the sooner the better. All relevant code should be ported to 2Geom.
EMF output uses a modified function from livarot for doing INTERSECTION on pairs of shapes because that was broken in 2geom. It is needed for generating "emulated gradients", consisting of slices of gradients, because there is apparently a huge bug in some Windows library preventing it from using its own native EMF gradient record. If these broken 2geom operators get fixed then this livarot dependency can be eliminated.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On 17-Nov-2013 08:52, Alex Valavanis wrote:
- libuemf - New contribution [7]: Is there a plan to push this to
distros? Would be good to enable an optional external build
That's my library, and I have no idea how to "push it" in this manner.
Note that most distros already have libemf, but when I tried to use that for Inkscape there were so many pieces missing that I found it easier to start fresh and write my own. At this point in libUEMF's development I am not entirely sure that having to use whatever version a distro might happen to have is a great idea, since I am still finding that a line here or there needs to be tweaked to to solve some issue or the other in Inkscape, at a rate of about once every couple of months. If we were using distro versions fixing these issues would be a bit of a pain.
Also EMF+ is coming along and I am just about ready to start adding that to Inkscape. None of that code is in the libuemf on sourceforge yet.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On 18 November 2013 17:44, mathog <mathog@...1176...> wrote:
That's my library, and I have no idea how to "push it" in this manner.
There's a nice way and there's a mean way ;-)
The "nice" way is to follow the long, convoluted packaging request process for each distro and wait for months or years because no applications depend on it so it isn't considered urgent.
The other option is to simply drop the library from Inkscape and provide a link in the release notes to the new dependency. The Inkscape package maintainers will effectively be forced into packaging the library by the multitude of users who are desperate to get the new version of Inkscape! I suspect that this generates bad karma, however..!
At this point in libUEMF's development I am not entirely sure that having to use whatever version a distro might happen to have is a great idea, since I am still finding that a line here or there needs to be tweaked to to solve some issue or the other in Inkscape, at a rate of about once every couple of months.
OK, that makes sense. Thanks. Once it's a bit more stable, we can always place a version requirement in the build files to ensure that the distro is up to date. Can I request, though, that you update the README in our copy of libuemf, so as to specify the version/source revision that we currently use? It makes it much easier to deal with merging upstream changes in future.
Thanks,
AV
Em Dom, 2013-11-17 às 16:52 +0000, Alex Valavanis escreveu:
- libdepixilize - New GSOC contribution. Any plans for this to be
released as a standalone package? Would be good to enable an optional external build.
Yes, I plan to release as a standalone package. But the library purpose is to serve Inkscape and I don't want to stabilize API yet.
And I should give commit rights/repo ownership to Inkscape developers.
participants (5)
-
Alex Valavanis -
Johan Engelen -
Krzysztof Kosiński -
mathog -
Vinícius dos Santos Oliveira