I took longer than I should have to understand the file organization in the repo, so I want organize to the files with the goal of having a project structure that can be easily understood.
The main problem is that the top-level of the repo is littered with utility files and directories. Just with the scripts, there are 14 .sh and 1 .bat file.
Therefore, I propose that all those scripts are moved to a new ‘tools’ directory.
I’m assuming all those scripts expect to be at the top level, and moving them to the ‘tools’ directory requires them to be modified, and possible to update documentation. These modification are a good thing because that inflexibility is what lead to the mess.
Not sure this would please the lead devs (I’m basically a translator, I did only a few modifications).
Top-level scripts are supposed to be here for ease of access and to let the choice.
For the rest…
I agree that the source structure is “heavy”, it has already been a bit reworked in the past but it is still quite messy.
And I’m not even talking about 5000+ lines sources which are a patchwork of mixed concerns.
Functions of hundreds of lines make me sick even though modern IDEs can handle direct access to them.
Also there are in-progress works and I’m not sure a deep change would be merged.
I made a separated module to avoid to introduce complexity and separation of concerns.
Based on ffmpeg module, it has different parameters, also a different configuration dialog.
“Multiplexed code” is adding conditions and removing lisibility (intention → goal → result).
That’s also the reason I like vertical alignment, then source has to be seen in its globality, not line-by-line.
And a separated module also permits to avoid to mess the original code with such formatting.
KISS
In general, as we operate in open-source code and wish more contributions, there is a limit in complexity that should be not reached.
Not everyone has a deep knowledge of the arcana of C++.
There is still a lack of documentation for the global structure of Synfig itself.
Code should be readable like a music sheet and its intention guessed without to check the documentation.
Of course it is nice to have real professional coders for the quality and correction (like you!), but think on the little occasional devs
I’m also expecting to write a tutorial on adding a module from this experiment.
But…
Synfig is open-source and you can still do a fork with a reworked structure
Not sure this would please the lead devs […] top-level scripts are supposed to be here for ease of access
I figured I’d be seen as the outsider who wants others to do what he wants, but that’s why I explain my reasoning in my posts. The top-level scripts grew beyond the benefit of having them there, and I’m just proposing to add 1 level of directory depth.
there are in-progress works
The nature of unstructured development is that the base is really a moving target. Ideally people would deal with changes by keeping their work in sync. The alternative, which is worse, is to stop development until someone else finishes their work
you can still do a fork
And that’s what I’m trying to avoid, as I feel my goals align with those of the current devs. In the short term (possibly long term too) the best thing for me personally would be to remove everything I don’t need and implement just the things I care about, I don’t even have to release the code because I wouldn’t distribute the binaries.
Instead I’m trying to advance the project as a whole, for example, I really don’t care at all about imagemagick, but I thought it would be a good first issue to solve so I made the pull request.
My role in the development of Synfig is limited and I contributed only a few to the code.
I’m helping in other ways (mostly for the forums and some administrative tasks).
I have my own opinion about how to code and priorities.
I’m not a spokeman, I just notice that sometimes there is a kind of rigidity and lack of documentation blocking new contributions.
And try to be a bit more diplomatic maybe
