Forum: Inkscape Summer of Code 2014

33a0818cf14f6003a8b3197dd902c21c?d=identicon&s=25 Josh Andler (Guest)
on 2014-02-24 20:15
(Received via mailing list)
Hey All,

We've been accepted again as a mentoring organization for Google's
Summer
of Code. This is the 10th year they've held it and our 10th year
participating! If you're a potential mentor or student, please sign up
at
melange (1).

If you are interested in participating as a student please visit our
page
on Melange (2) to find links to our Ideas for summer projects on our
wiki
and our developer mailing list. As usual, please either introduce
yourself
on our developer mailing list or let us know what you're interested in
working on this year.

Cheers,
Josh

(1) http://google-melange.appspot.com/
(2) http://google-melange.appspot.com/gsoc/org2/google...
979333bd98940bb1d40aefb1820fcfa9?d=identicon&s=25 Bryce Harrington (Guest)
on 2014-02-25 08:53
(Received via mailing list)
On Mon, Feb 24, 2014 at 11:14:41AM -0800, Josh Andler wrote:
> on our developer mailing list or let us know what you're interested in
> working on this year.
>
> Cheers,
> Josh
>
> (1) http://google-melange.appspot.com/
> (2) http://google-melange.appspot.com/gsoc/org2/google...

Here's also a bunch of good ideas Krzysztof posted several weeks back.
Some of these may be a little too ambitious to do in a summer so would
need scoped down.

1. Improve Icon Cache
Convert the icon cache (icon.cpp) to create the PNGs with a directory
structure and index file matching the icon theme specification. Use
this to get rid of customized classes InkAction, SPIcon, and so on.

2. Remove dom/ directory
This directory contains strange code which is barely used. The only
class which is actually used is the URI class.

3. SAX parser
Convert the current document parser from DOM to SAX, so that it
creates our XML tree right away, instead of creating the libxml2 DOM
tree, creating our tree to match it, then freeing the libxml2 tree.
This should improve performance and allow more robust fixes for some
problems.

4. Rewrite of Geom::PathVector and Geom::Path
Change PathVector to be a real object instead of a std::vector of
Path, so that it can have useful methods, similar to curves.
Move the copy-on-write idiom to the PathVector object, rather than
using it in the Path.
Investigate whether it is possible to store subpath data in a more
compact way and make the Curve objects only convenience facades. Right
now, if the path has only linear segments, every point is stored
twice.
Apply the following renames to match SVG terminology:
Path -> Subpath
PathVector -> Path

5. Boolean operations and stroking
Add methods to PathVector objects:
a) Set operators (& | - ^), which perform the relevant boolean
operation on the paths. Use the algorithm from CGAL or devise a new
robust algorithm.
b) stroke(double line_width, LineJoin join, LineCap cap, double
miter_limit), which performs the stroke-to-path operation.
c) stroke(double line_width, LineJoin join, LineCap cap, double
miter_limit, std::vector<double> const &dasharray), which performs
stroke-to-path with dashing.

6. Renderer improvements
This is a big task which has several sub-tasks:
a) Unify the interactive and non-interactive renderers. (It would be
desirable to have one codebase, but we need to investigate a little
more whether this is practical.)
b) Pluggable renderers - allow writing rendering backends which use
something other than Cairo, e.g, OpenGL, Skia, Mozilla Azure or GEGL.
c) OpenGL renderer - implement an OpenGL 3.x+ canvas which would
render Beziers using this method:
http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html
Investigate whether this generalizes to S-basis and circular arcs.
Since the described method does not handle stroking, this work depends
on 5.
Also check how OpenGL path rendering is implemented in Qt, since
apparently the performance there is very good.
http://zrusin.blogspot.com/2011/09/nv-path-rendering.html

7. Typed XML tree
Improve XML tree so that it can store some attributes in parsed,
binary form. The main target of this are the data URIs used to embed
images, which could be stored as binary data only. This work should be
done after completing task 3 (SAX parser), as this will make it
easier.

8. Shape manipulators
The idea here is to rewrite shape tools in the same paradigm as the
node tool. Instead of storing all information about the shape in knots
which differ only by their callbacks, allow to store information in a
higher-level manipulator object. This would enable things like
dragging the side of a rectangle and consistent outlining / update
preferences for all shapes.

9. Improve the performance of layer visibility
Right now, toggling layer visibility causes massive changes in the
display tree, because the entire toggled layer is invalidated at the
XML level. This results in very bad performance for an action which
should nearly instantaneous. Improve the control flow so that only the
visibility of the object representing the layer is turned off, but the
remainder of the display and object tree is leaved alone.

10. Common build system for all platforms
Migrate the build system to Waf for all platforms. Alternatively, if
there are important technical reasons why Waf is not suitable, port
all necessary features to the CMake build system and remove Autotools.

11. Remove SPCurve
SPCurve is a thin wrapper around Geom::PathVector which exists for
historical reasons. Its functionality should be added to PathVector,
and SPCurve should be purged.

12. Use a different data structure for Inkscape::Selection
Inkscape::Selection currently uses GSList as its data structure. This
is suboptimal, since a very common operation is checking whether some
object is selected. Change Inkscape::Selection so that its underlying
structure is a boost::multi_index container which implements the same
semantics as Java's LinkedHashSet.

13. Remove all use of GList and GSList
These GLib data structures are poorly designed (they are simple lists
without sentinels, leading to blunders such as O(N) performance when
appending to a doubly-linked list) and not type-safe. Replace all uses
with standard C++ containers or suitable Boost containers.

14. Box blur
Currently we always use a very accurate method to compute the Gaussian
blur filter. Add an alternate method which approximates Gaussian blur
using three stacked box blurs (simple averages). This is detailed in
the SVG 1.1 SE specification.

15. GTK3 on Windows
Rebuild the Windows devlibs so that they contain GTK3. Make the
Windows port work with them, possibly sending the appropriate patches
to the GTK maintainers.

16. Migrate argument parsing to GOption and remove the dependency on
popt
Write test cases for this bug, so that the patches can be accepted into
GLib:
https://bugzilla.gnome.org/show_bug.cgi?id=522131
If this proves hard, simply apply the patch to the devlibs. Once this
is done, port argument parsing to GOption.

17. Extension system improvements
Refactor the extension API. Clean up the kludgy class hierarchy,
possibly using multiple inheritance. Use GInputStream and
GOutputStream as parameters instead of file paths, so that things like
the clipboard can have

18. Robust ID handling
Currently ID clash resolution is implemented as a giant switch over
object types, listing every possible dependency. Replace this with
virtual methods on objects, which provide information on what each
object refers to. Improve behavior when a dependency of an object is
deleted, and when IDs are changed / deleted from the XML editor.
7f6f9e75239bfcc5bfb41014e9dc9a26?d=identicon&s=25 Martin Owens (Guest)
on 2014-02-25 17:59
(Received via mailing list)
On Mon, 2014-02-24 at 23:51 -0800, Bryce Harrington wrote:
> 2. Remove dom/ directory
> This directory contains strange code which is barely used. The only
> class which is actually used is the URI class.

That's worth knowing, I'll hack that up in my branch as I add the data
uri support.

Martin,
33a0818cf14f6003a8b3197dd902c21c?d=identicon&s=25 Josh Andler (Guest)
on 2014-02-26 12:28
(Received via mailing list)
On Tue, Feb 25, 2014 at 10:10 AM, Krzysztof Kosiński
<tweenk.pl@gmail.com>wrote:

> That's true, but the rules for GSoC are quite restrictive when it
> comes to teamwork - I'm fairly sure that joint applications (e.g. 3
> students applying to participate in this model) are not allowed at
> all.
>

This is correct. It would definitely not be allowed. They require very
clear and obvious separation of work. My guess is that it's to ensure
that
each student is doing what they are supposed to and that they are not
subject to failure due to shortcomings imposed by other students.



> A safer bet would be to merge some of the items into larger projects.
>

If someone with a good sense of which ones would be appropriately
combined
would be willing to do so and add them to
http://wiki.inkscape.org/wiki/index.php/Google_Sum...
would be greatly appreciated.

Cheers,
Josh
Faf7c5b7f2c3eb1a151d0b4f73345397?d=identicon&s=25 Tavmjong Bah (Guest)
on 2014-02-26 13:08
(Received via mailing list)
I added Krzysztof's list to Inkscape GSOC wiki page.
1725020ed58eea0c8e31f86ba702cb69?d=identicon&s=25 Jon Cruz (Guest)
on 2014-02-26 17:33
(Received via mailing list)
On Feb 25, 2014, at 8:58 AM, Martin Owens wrote:

> On Mon, 2014-02-24 at 23:51 -0800, Bryce Harrington wrote:
>> 2. Remove dom/ directory
>> This directory contains strange code which is barely used. The only
>> class which is actually used is the URI class.
>
> That's worth knowing, I'll hack that up in my branch as I add the data
> uri support.


Actually the intent of this one had been explained to others in the
past.
The dom directory was done in preparation of improving the extension
system by providing a live DOM interface to plugins. We've even had
members of the SVG and XML committees review and endorse the approach.

A better task might be to follow-up on Bob's work with the next step and
get the DOM exposed.
7f6f9e75239bfcc5bfb41014e9dc9a26?d=identicon&s=25 Martin Owens (Guest)
on 2014-02-26 17:55
(Received via mailing list)
On Wed, 2014-02-26 at 08:32 -0800, Jon Cruz wrote:
> A better task might be to follow-up on Bob's work with the next step
> and get the DOM exposed.

Sounds like we were all on the wrong page with this one. Several
developers seemed to think dom was on it's way out.

Does this mean uri.cpp / uri.h should be depricated?
Should uri.cpp shift from using libxml to dom?
What does the css parsing mean for libcroco?

Why do we have a giant blob of code, shouldn't it be a library that many
people could take advantage of?

Thank fluctuations I put it in a branch though.

Martin,
33a0818cf14f6003a8b3197dd902c21c?d=identicon&s=25 Josh Andler (Guest)
on 2014-02-26 19:31
(Received via mailing list)
On Tue, Feb 25, 2014 at 5:06 PM, Nathan Hurst <njh@njhurst.com> wrote:

> The whole point of kanban is that each task is self contained.  It's
> easy to assess what each student has done, look at the bzr logs, look
> at the tasks undertaken, look at their report.  Students can't affect
> each other, because at the frontier all the tasks are independant.
>

The way you had said it earlier, you had mentioned they would work off
the
same kanban queue as a team. The students are supposed to have firm
proposals outlining what they will specifically accomplish and what the
corresponding timeline looks like. Because of this, it's not really
possible to have multiple students working from a pool of tasks to be
completed.

Honestly, I like your idea, however I don't believe there is a way to
achieve this with GSoC that Google would approve of.

Cheers,
Josh
9625234ca6ba67c5e03b0f84219141fc?d=identicon&s=25 M.H. van der velde (Guest)
on 2014-02-27 09:14
(Received via mailing list)
Hi Everybody,

Is there a possibility from either within Inkscape or by using an
external script (PHP, Ruby, Python, Bash, TurboPascal ;-)  ) to convert
every layer in Inkscape to a separate SVG file? Preferably, using the
name of the layer as the file name.

I tried some Google research, but all I found were references to the
possibility of extracting bitmaps from Inkscape-layers.

Thanks in advance,

Maarten
979333bd98940bb1d40aefb1820fcfa9?d=identicon&s=25 Bryce Harrington (Guest)
on 2014-02-28 02:32
(Received via mailing list)
On Wed, Feb 26, 2014 at 12:06:19PM +1100, Nathan Hurst wrote:
> > clear and obvious separation of work. My guess is that it's to ensure that
> > each student is doing what they are supposed to and that they are not
> > subject to failure due to shortcomings imposed by other students.

That, certainly.  Also, whenever there are multiple pieces being
developed in parallel it requires a high degree of communication to
ensure both projects end up fulfilling their requirements in a
compatible fashion.

> The whole point of kanban is that each task is self contained.  It's
> easy to assess what each student has done, look at the bzr logs, look
> at the tasks undertaken, look at their report.  Students can't affect
> each other, because at the frontier all the tasks are independant.

When I was doing development on Launchpad we used Kanban, so I'm
reasonably familiar with the process.  But it's nothing magical, it is
just a way to organize and coordinate sequential interdependent tasks.
It still requires a fair bit of upfront planning and coordination.  It's
like our traditional Roadmap system on steroids (I bet we could even
implement Kanban *within* Inkscape with a bit of coding if we wanted.)

The team I was on had only 6 members, and frankly Kanban was a bit
overkill for us.  I think it's best suited for larger teams.  Or maybe
teams with finer grained tasks than we had, or that require more
intensive team coordination.

So, I would love to play with Kanban more in team coordination, but I
think for GSoC even if we did have 2-3 students working together I'm
skeptical it would help all that much.

Bryce
7f6f9e75239bfcc5bfb41014e9dc9a26?d=identicon&s=25 Martin Owens (Guest)
on 2014-03-01 04:42
(Received via mailing list)
Hi Maarten,

I've wanted this functionality too in the past... so I've built it. You
can download an extension to save an svg as a collection of svg files
here:

http://sexternalharddrive.com/tar_layers_inkscape_...

It outputs a tar file (because we can only output a file, not to a
directory). I've also committed this to trunk so it'll be available for
everyone in the next version of inkscape.

Martin,
9625234ca6ba67c5e03b0f84219141fc?d=identicon&s=25 M.H. van der velde (Guest)
on 2014-03-07 09:47
(Received via mailing list)
Hi Martin,

Thanks for your script. It should do exactly what I need, but
unfortunately, I cant test it. I installed it, found it under save as
and tried running it...

and ran into the notorious LibXML problem  that I tried to fixe earlier
on  to use the beautiful plethora of extensions :(


I tried many of the solutions one finds by googling, but none of them
worked. It might of course be that one solutions ruins the other.

( I tried:
running a special Mac version of inkscape (Mac OS X Mountain Lion x86_64
packaging of  0.48.4) Works really nicely, fixes a lot of Mac issues,
except, for me, this one)
Chaning the inkscape.bin file (line 32, export
VERSIONER_PYTHON_VERSION=2.7 to export VERSIONER_PYTHON_VERSION=2.6)
installing LibXML using home-brew.
installing Inkscape using home-brew)

Thanks again!

Maarten
9625234ca6ba67c5e03b0f84219141fc?d=identicon&s=25 M.H. van der velde (Guest)
on 2014-03-07 09:52
(Received via mailing list)
My use-case  might be of interest to other Inkscape users as well
(especially those who have a function LibXML library :-)   )

The reason I would like this functionality is so I can create
-a library of icons in ONE file,
-export them all to separate SVG-files (with meaningful names)
-and import them into the icomoon.io web-app that
-transforms the icons into an icon font :D


Maarten




Inkscpae is brilliant tool for making icons, I prefer it much above
Illustrator.
Aefd46e73e6b7449c5ce1ce0156797d2?d=identicon&s=25 su_v (Guest)
on 2014-03-07 10:37
(Received via mailing list)
On 2014-03-07 09:45 +0100, M.H. van der velde wrote:
> I tried many of the ‘solutions’ one finds by googling, but none of them
> worked. It might of course be that one ‘solutions’ ruins the other.

Could well be.

Assuming your system Python version is the one provided (and maintained)
by Apple and has not been tinkered with: download a fresh copy of the
official Inkscape package (0.48.2) from inkscape.org and follow the
instructions here:
<https://bugs.launchpad.net/inkscape/+bug/819209/co...


Cheers, V
9625234ca6ba67c5e03b0f84219141fc?d=identicon&s=25 M.H. van der velde (Guest)
on 2014-03-07 14:14
(Received via mailing list)
Su_V, Martin,

Thank you both for your help and suggestions. I finaly got it working.
Great! This is really helpful.

Martin, I do not know if its on purpose, but hidden layers do not get
exported. I can understand your choice here, but when working with lots
of layers, it might prove impractical, as its not possible to hide/show
all layers in Inkscape. But, again, thanks a lot!

Maarten
7f6f9e75239bfcc5bfb41014e9dc9a26?d=identicon&s=25 Martin Owens (Guest)
on 2014-03-07 15:42
(Received via mailing list)
On Fri, 2014-03-07 at 14:13 +0100, M.H. van der velde wrote:
> Martin, I do not know if it’s on purpose, but hidden layers do not get
> exported. I can understand your choice here, but when working with
> lot’s of layers, it might prove impractical, as it’s not possible to
> hide/show all layers in Inkscape. But, again, thanks a lot!

There's no code that checks to see if layers are visible or not. But
maybe something else is happening.

Martin,
Aefd46e73e6b7449c5ce1ce0156797d2?d=identicon&s=25 su_v (Guest)
on 2014-03-07 15:54
(Received via mailing list)
On 2014-03-07 14:13 +0100, M.H. van der velde wrote:
> (...) but when working with lot’s of layers, it might prove
> impractical, as it’s not possible to hide/show all layers in
> Inkscape.

Check the context menu of the selected layer in the Layers dialog ...


Cheers, V
9625234ca6ba67c5e03b0f84219141fc?d=identicon&s=25 M.H. van der velde (Guest)
on 2014-03-07 16:14
(Received via mailing list)
and it says hide other layers.

Thanks! Missed that one completely. And I *realy* searched for it! :D
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.