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...
on 2014-02-24 20:15
on 2014-02-25 08:53
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.
on 2014-02-25 17:59
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,
on 2014-02-26 12:28
On Tue, Feb 25, 2014 at 10:10 AM, Krzysztof Kosiński <firstname.lastname@example.org>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
on 2014-02-26 13:08
I added Krzysztof's list to Inkscape GSOC wiki page.
on 2014-02-26 17:33
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.
on 2014-02-26 17:55
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,
on 2014-02-26 19:31
On Tue, Feb 25, 2014 at 5:06 PM, Nathan Hurst <email@example.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
on 2014-02-27 09:14
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
on 2014-02-28 02:32
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
on 2014-03-01 04:42
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,
on 2014-03-07 09:47
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
on 2014-03-07 09:52
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.
on 2014-03-07 10:37
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
on 2014-03-07 14:14
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
on 2014-03-07 15:42
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,
on 2014-03-07 15:54
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
on 2014-03-07 16:14
and it says hide other layers. Thanks! Missed that one completely. And I *realy* searched for it! :D