This is why Synfig has few new devs

I’m gonna be real with you all after a lot of frustrating experiences.

I’ve been trying to get into Synfig development because the Software is the only FOSS alternative that focuses on animating vector shapes. You can see from old posts that I have been interested for a while. However I’m considering just throwing the towel and settle for raster animation:

  • It’s hard to navigate the fourm. Discourse’s UI (at least the default) has many usability issues, for example, the first screen has two columns of the same size next to the other there’s no contrast between one section or the other. If you read and hover over every piece of text, then you finally grasp what things mean in the user interface, for example in the ‘Lastest’ column, if you hover over the numbers, you notice that the numbers are actually the number of replies to the post, but there’s no other indication. There are many other issues.

  • There’s no direct link to the dev docs at Welcome to Synfig developers documentation! — Synfig developers docs documentation . Sure, you are directed to a part of them if you click ‘Building and installing from source’ on GitHub, but even the old wiki is easier to find.

  • I’ve been trying to build Synfig on Windows. I tried the autotool method first. No go. Searching the forums, the recommendation is ‘autotools is broken, use cmake’. If the autotools are deprecated, why not remove them? Being able to build the software is the most essential requirement for development ever.

  • When trying cmake it hangs on “[0/396] Generating …/…/output/Release/share/synfig/icons/classic/action_unexport_icon.png”. I’m currrently debugging this.

  • Documentation is poor. I know it is mostly because of lack of man power and that this can be changed through pull requests, but I wrote it here for completeness sake. Chiefly, there’s no official path for new devs to start.

Would it be possible to migrate from Discourse’s default UI? could a one true well-supported building process be defined?

2 Likes

I isolated the command that makes building hang up:

$ C:/Users/coz/Desktop/Agames/tools/msys64/home/coz/synfig/cmake-build-msys-make/output/Release/bin/synfig.exe about_icon.sif -o C:/Users/coz/Desktop/Agames/tools/msys64/home/coz/synfig/cmake-build-msys-make/output/Release/share/synfig/icons/classic/about_icon.png --time 0f

This is the output

synfig(7432) [14:45:47] info: rendering threads 16
synfig(7432) [14:45:47] info: Loading lyr_freetype…
synfig(7432) [14:45:47] info: Loading lyr_std…
synfig(7432) [14:45:47] info: Loading mod_bmp…
synfig(7432) [14:45:47] info: Loading mod_dv…
synfig(7432) [14:45:47] info: Loading mod_example…
synfig(7432) [14:45:47] info: Loading mod_ffmpeg…
synfig(7432) [14:45:47] info: Loading mod_filter…
synfig(7432) [14:45:47] info: Loading mod_geometry…
synfig(7432) [14:45:47] info: Loading mod_gif…
synfig(7432) [14:45:47] info: Loading mod_gradient…
synfig(7432) [14:45:47] info: Loading mod_imagemagick…
synfig(7432) [14:45:47] info: Loading mod_jpeg…
synfig(7432) [14:45:47] info: Loading mod_noise…
synfig(7432) [14:45:47] info: Loading mod_openexr…
synfig(7432) [14:45:47] info: Loading mod_particle…
synfig(7432) [14:45:47] info: Loading mod_png…
synfig(7432) [14:45:47] info: Loading mod_ppm…
synfig(7432) [14:45:47] info: Loading mod_svg…
synfig(7432) [14:45:47] info: Loading mod_yuv420p…
synfig(7432) [14:45:47] info: Loading mod_mng…
synfig(7432) [14:45:47] info: Loading mod_magickpp…
synfig(7432) [14:45:47] info: Loading file: about_icon.sif
synfig(7432) [14:45:47] info: Loading file: logo.sif
synfig(7432) [14:45:47] info: target name not specified - using magick++
synfig(7432) [14:45:47] info: w: 128, h: 128, a: 1, pxaspect: 1.000000, imaspect: 1.000000, span: 2.828427
synfig(7432) [14:45:47] info: tl: [-1.000000,1.000000], br: [1.000000,-1.000000], focus: [0.000000,0.000000]
about_icon.sif ==> C:/Users/coz/Desktop/Agames/tools/msys64/home/coz/synfig/cmake-build-msys-make/output/Release/share/synfig/icons/classic/about_icon.png: DONE

After that it never exits, and the file about_icon.png is nowhere to be found. Maybe it’s related to this bug. This steps work if the target is imagemagick, but won’t work with the targets png and magick++.

Normally, this is the official building process: GitHub - morevnaproject/morevna-builds
Sometimes autotools is broken because not updated, while cmake is more in fashion.

About the documentation…
I would like more “How to” for adding a feature and description of internal mechanism for the new devs.
It is way too much overcomplicated to start
See my comments in feat: support for animated webp with transparency by BobSynfig · Pull Request #2933 · synfig/synfig · GitHub

I decided to stick with Synfig, so I’ll actually try to get involved. However once the ‘Synfig ecosystem’ is good enough, I’ll move on. Hopefully by then there will be a couple new devs.

My battle plan:

  1. Regarding Discourse, sometime in the near future I’ll test a few themes to propose changes
  2. Before moving to work to Synfig I’m gonna have to get it to build
  3. After getting it to build, the first thing is fixing the build process
  4. There are a bunch of bugs in Synfig that bother me. Maybe I’ll squash a couple
  5. Docs also bother me, so I’ll help with migration, but I’m not sure if I’ll do that before or after bug squashing
  6. Regarding creating a path for newbies, I’ll do that after working on the docs
  7. After all that, there are a couple new features that I’d like in Synfig, so I may add them
  8. And then I’ll vanish into the wild unknown :slight_smile:
3 Likes

Obviously it works as morevna-builds is based on standard packages / Docker.
But in the case of Windows builds we depend on the changes in MinGW which regularly “changes the rules”: Failed to build synfig-core when cross-compiling with MinGW 8.0 on Debian 11 · Issue #2939 · synfig/synfig · GitHub
A standard Docker image with all the requirements and libs installed, update regularly would be great and would avoid any questionning :stuck_out_tongue:

After such investment? It would be a waste :stuck_out_tongue:

1 Like

Yeah… ‘it works because it works on someone else’s system’ is not a good measure of proper support for multi-platform software. That is what leads to the current problems.

Dependencies changing are out of the developers’ hands. However I’m pulling the HEAD of the master branch of the official repo and using the official instructions. The build should NOT fail due to an issue reported more than a year ago.

If the build system is failing me, it’s unthinkable that I’ll even consider also dealing with Docker.

I just want to use Synfig. I’m not getting involved because I want to develop it. If it could interoperate with Inkscape and be less buggy, I wouldn’t have even looked at the source, so if I can get it to do what I want it to do, it wouldn’t be a waste at all :slight_smile:

Regarding the build system, how should I go to reach a consensus (there doesn’t seem to be a method of messaging developers in general) regarding if support for autotools should remain, or if support for cmake should remain? Cmake has better Windoze support (Visual Studio), but don’t really care about that. However, other devs may prefer one or the other, but it would be best to stick to one of them. That way I can focus on fixing one and remove the other afterwards.

Also noticed a typo in my original post, but it’s not letting me edit it. Is it because it’s less than 24 hours since the last edit? that’s the kind of thing that makes the forum frustrating.

My advice is to use a Virtual Machine under Linux as dev/build/test system, as Linux is the main platform, and even to use it for exploitation of Synfig.
(Yeah, I refer often to Virtual Machine as a workaround).
Then you can be sure that next time a version will be published, the “standard” build system will be functional, the team will do the necessary to make it work.
When I was using Windows, this is what I was doing.
Now I’m under Linux, dev in general is ways easier :stuck_out_tongue:

1 Like

Hmm. TBH I do prefer Linux. I have the issue that I spend most of my time on Windows because the company I work with only approves of Windows and Mac.

-sigh- Sorry for all the text, I know I write a lot.

Either way, I do think that a single building system should be kept, though it sounds that the preference is to keep multiple build systems. Maybe whatever advantage the autotools system has could be integrated into the CMake system? I’m saying that because I was under the impression that the whole point of adding CMake to Synfig was to support Visual Studio.

Yes, Linux dev is definitely easier.

Oh BTW I managed to build with CMake. I’m still tweaking a few things, and then I’ll start hacking away.

2 Likes

Hi!

There’s no direct link to the dev docs

Do you mean add it to the readme on github?

If the autotools are deprecated, why not remove them?

It is not deprecated. Some contributors is using it. Also it used by maintainers to build linux packages.

  • When trying cmake it hangs on “[0/396] Generating …/…/output/Release/share/synfig/icons/classic/action_unexport_icon.png”. I’m currrently debugging this.

libsynfig contains a large number of exported symbols, which leads to linking problems. There is no problem with that on Linux/Mac, but this is still an issue on Windows. You can switch to Release build to workaround this issue, or switch to Clang/LLVM linker if you need debug build. Also you can dig into base_types.cpp just to get better understanding what happening. Fixing this issue will also fix autotools build in MSYS2 environment (but it’s complicated).

I’m saying that because I was under the impression that the whole point of adding CMake to Synfig was to support Visual Studio.

As for me CMake is my primary build system on all OS (Mac/Win/Linux).
It also automatically tracking dependencies over the whole project (autotools as far as i know tracking only part of the project ETL/core/studio). And yes, without CMake we cannot support VS, but this is not the primary reason.
Also, VS was planned to be the default compiler for Windows, at least until we fix the problem with the large number of exported symbols.

Documentation is poor

True story. We are mostly busy by refactoring and cleaning the current codebase, so any help is appreciated.

I decided to stick with Synfig, so I’ll actually try to get involved.

Welcome!

2 Likes

Do you mean add it to the readme on github?

I’d suggest that, but I would create a section under ‘Install’ titled ‘Contributing’ and write the points you made in How to get started with contributions . If it’s okay, I can do the edit and make the pull request.

It is not deprecated. Some contributors is using it. Also it used by maintainers to build linux packages.

I see. I’d prefer a single build system, but I think there are better times and places to discuss that, so I’ll be quiet about this for now.

libsynfig contains a large number of exported symbols, which leads to linking problems

I actually noticed there has been a lot of activity lately, including improving the build system

Welcome!

I appreciate that, despite writing an inflammatory post and behaving like an angry dwarf, so sorry about That @BobSynfig. I’ll do my best to be kinder to everyone.

On the brightside, if I had not behaved like that I wouldn’t have gotten involved, so if I do end up being helpful I suppose it will even out.

Edit BobSynfig: Added lines to separate blockquotes from answers

1 Like

I’m fine with you remarks and fully understand your frustration, especially about dev docs :wink: