[GSoC 2020] Google Summer of Code 2020

Hi everyone! We decided to apply for Google Summer of Code program this year again. ^___^

The organization application period is open now and it will close on Wednesday, February 5th. - https://opensource.googleblog.com/2020/01/google-summer-of-code-2020-is-now-open.html

Now it is time to prepare all necessary docs for application.

This year I am volunteer to participate as an Admin. I can also act as Backup Mentor, if such need arise. :slight_smile:

Questions we should answer first:

  • Who is willing to participate as mentor? It would be nice if you provide a project ideas that you are willing to mentor. If you have potential student who can carry the project - please mention that too.
  • Who can help with preparing application docs? We have docs for previous year here - https://synfig-docs-dev.readthedocs.io/en/latest/gsoc/2019.html. Most information can be copied.
  • Help to discuss ideas for student’s projects. See list from previous year - https://synfig-docs-dev.readthedocs.io/en/latest/gsoc/2019/ideas.html#projects-ideas.
    Remember that we can accept idea only if there are someone who is willing to mentor it. In any case, post your crazy ideas in this thread and get fellow devs interested. :slight_smile:
  • Prepare list of simple issues to test skills of aspiring students. We need to examine list of existing issues in our tracker and mark some of them with “good-first-issue”, “help-wanted” and “Easy” labels. Adding simple issues is also appreciated.



Hi, guys!

Here are my ideas for GSOC 2020.


  1. Change the layout of the builded files inside the cmake-build directory:
    a) Create a subfolder with assembly type (Debug / Release)
    b) Inside it, create a folder tree that matches the structure that Synfig expects (bin / etc / lib / share);
  2. Finish the make_images cmake target. Because the paths will already coincide with what Synfig expects, then everything should be works fine. As for now this target fails because Synfig can’t load needed libraries (for that step we will use the SYNFIG_ROOT_DIR environment variabe as a temporarily hack);
  3. Fix algorithms for searching libraries in Synfig, relative to the called binary, and remove the SYNFIG_ROOT_DIR hack in step 3 (as for now part of Synfig paths is hardcoded so this part needs to be rewritten);
  4. Add the ability to disable any optional module or all of them, this will allow building on Debian systems (there is a problem with libmng on Debian-based systems). Also maybe add a custom CMake search for libmng?;
  5. Try to build Synfig using vcpkg (https://github.com/microsoft/vcpkg) - they do not have some libraries which Synfig depends, but after disabling all the optional dependencies, maybe this will be enough for us. In case something critical is missing - add issue with a request to add missing library. This will allow us to build Synfig using MSVC on Windows;
  6. Start implementing CPack to prepare .deb and .nsis files.

P.S. I will update this post later.


@ice0 That’s cool! I like the fact that there is a specific plan on CMake improvements project. And also it’s starts with some short tasks, so incoming students can proof their skills before the actual coding period starts.

BTW, that reminds me about one more item for our TODO list.
We need to prepare for incoming flow of aspiring students - make a collection of simple/good-first issues, so they can start diving into Synfig code. :slight_smile:


@ice0, I guess first items from your plan can be submitted as “good-first-issue” in bugtracker. ^___^

1 Like

Hello everyone,

After a discussion with @KonstantinDmitriev, we have decided to extend the Lottie export project which was my GSoC project last year.
Here I am sharing of what is expected from you to implement in this project this year[Will keep on updating this, keep an eye]

  • Export outlines without variable widths (that way we get native Lottie outlines and will make animation playback much faster)
  • Export of following layers (Will need proof of the existence of the following layers)
    • Advanced outline layer
    • Gradients
    • Duplicate layer
    • Bones (Add support for handling group transformations)
    • Text Layer
    • Blur Layer
    • Motion blur layer
    • Radial blur layer
    • Color correct layer
    • Luma key layer
    • Curve warp layer
    • Noise distort layer
    • Spherize layer
    • Twirl layer
    • Bevel layer
    • Stroboscope layer
    • Julia set layer
    • Mandelbrot set layer
    • Shade layer
  • Add animation to the addition/deletion of bline points
  • Use winding (in adobe AE) instead of masks to generate all the shape layers, this way we will be able to support even/odd winding.
  • Implement the remaining convert methods: https://wiki.synfig.org/Convert

I will be adding some issues related to Lottie in the bugtracker.
Here is one of them:

P.S. You can refer to the information regarding Lottie project here


Hi everyone, I’m student hoping to participate in gsoc this year.

I was reading the code structure and it said the opengl rendering is as of now broken. How much of it is broken? Are there parts in the opengl renderer that have not been implemented?

If so, could it be viable project idea for gsoc?

1 Like

I am a student hoping to participate in GSOC in 2020, so what do you guys as developers suggest for things i can contribute right now to synfig, so as to increase my chances of getting selected by your organisation.

1 Like

@UltGamer007 You can look for issues by this tags. I will add more issues a bit later.

1 Like

Hi @Jedi18! Thank you for your interest! Right now we have rewriting of software renderer in progress, so it is a bit early to do OpenGL fixing/developmentю

BTW, I still waiting for help with this -

The deadline (February 5th) is approaching.

1 Like

I will create a PR to synfig docs regarding the same.


@AnishG Thank you! :slight_smile:

1 Like

What about:

  • convert deprecated Gtk::Main to Gtk::Application (since 2012)
  • get rid of deprecated Gtk::StockId (since before 2013)
  • convert deprecated Gtk::Action to Gio::Action (since 2016)
  • convert/get rid of deprecated Gtk::UIManager to Gtk::Builder (since 2013)
  • a python/ruby/lua interactive console for plugin coding/testing : it can be used for synfig document handling and;or GUI-related. It would be an alternative to call python binary.

As the deadline for submitting the GSoC org application is closing in, I guess we should submit the project ideas as a P.R. here: https://github.com/synfig/synfig-docs-dev/blob/master/docs/gsoc/2020/ideas.rst

ping @ice0, @rodolforg

Also @KonstantinDmitriev, could you look into project ideas and check what all needs to be updated because most of the ideas are from the previous year.

1 Like

I think this is great addition, but I am afraid this could be too big task to be handled in 3 months (I think we should carefully plan API here, taking in account examples how this done in other products - Blender, Krita, GIMP, and commercial ones).

I like this, but leaving the final decision about this to @ice0.

Synfigapp is already an API. Maybe restrict the plugin approach to execute synfigapp::Actions? It would be just a matter to “port” a simplified version of basic data structures (layer, canvas, params, keyframe, valuebase).

With SWIG, it relatively easy to build the bridge C++ <-> Python/Lua.

1 Like

Another alternative is to implement frame-by-frame animation “tools”, such as improving Switch layer handling.

  • “Auto-switch” tool:

    1. User clicks on a Switch layer, then press this (toggle? radio?) tool button.
    2. Now, when user clicks on a timeline frame, it automatically creates a new waypoint that changes/animates the “Active Layer Name” or “Active Layer Depth” parameter of the selected Switch layer. The name or depth value changes follow the tree hierarchy order.
    3. User keeps clicking on different frames (step 2) to add new waypoint with different value. Process stops when user selects a not-inner layer of the Switch layer or selects none (or toggle back this toolbutton).
  • “Manual switch” tool:

    1. User clicks on a Switch layer, then press this (toggle? radio?) tool button.
    2. Now, the user clicks on a timeline frame, and then on a inner layer of the selected Switch layer.
    3. Synfig then automatically creates a new waypoint that changes/animates the “Active Layer Name” or “Active Layer Depth” parameter in order to refers the selected layer contained in the Switch layer.
    4. User repeats steps 2-3 to place new waypoints. Process stops when user selects a not-inner layer of the Switch layer or selects none (or toggle back this toolbutton).

This was suggested by Ricardo Graça, a professional animator that previously used Synfig a lot, but now switched to Blender for 2D animations… He gave me a few more ideas, but I’m still talking to him to better understanding.


That’s true.

Yes, that could be a way to go. If we select this idea, then we will need someone who is willing to mentor this project (in case if there will be a good student for it). :slight_smile:

1 Like

I have reviewed and filled in our GSoC application - https://synfig-docs-dev.readthedocs.io/en/latest/gsoc/2020/application.html

Looking forward to your PRs for Ideas List! :slight_smile: - https://synfig-docs-dev.readthedocs.io/en/latest/gsoc/2020/ideas.html


@AnishG I suggest to formulate the Lottie improvement idea a bit differently - how about this “Add support for exporting Skeletons to Lottie”. That makes the project more focused and easier to understand. And I think adding a skeleton export is already a big task. The addition of other layers could be a part of it, or part of proof-of-skill tasks for aspiring students. :slight_smile:

1 Like

@ice0 Looking forward to see your CMake project in ideas list :slight_smile: