Looks good.
I tested the script on Linux and I see some problems here.
requirements.txt contains a BOM (byte order mark), so it is not easy to edit on Linux.
This is what it looks like when you try to edit it using the nano editor:
It stops on install step because it can’t find pywin32.
Collecting Pygments==2.17.2
Using cached pygments-2.17.2-py3-none-any.whl (1.2 MB)
Requirement already satisfied: PyJWT==2.8.0 in /home/ice0/.local/lib/python3.10/site-packages (from -r requirements.txt (line 33)) (2.8.0)
Requirement already satisfied: PyNaCl==1.5.0 in /usr/lib/python3/dist-packages (from -r requirements.txt (line 34)) (1.5.0)
Collecting python-dateutil==2.8.2
Using cached python_dateutil-2.8.2-py2.py3-none-any.whl (247 kB)
ERROR: Could not find a version that satisfies the requirement pywin32==306 (from versions: none)
ERROR: No matching distribution found for pywin32==306
If I remove all dependencies except GitPython and PyGithub, everything installs successfully.
I suggest you to add Github actions (Features • GitHub Actions · GitHub) to your repository so that it automatically checks if everything is ok across different OSes.
Looks awesome!
I suggest adding a CMake or make makefile and adding the required dependencies to the readme file (curl and jsoncpp).
We have planned simple HTML elements (mainly <div>, <ul>, <li>) so that they can be easily integrated with custom CSS into any design (eg dark/light theme).
@omkar334 (Omkar, I hope it will be useful to you too)
We want to give the PR contributor the opportunity to see how their contribution will change the current release notes (maybe an automated comment from bot with a screenshot and a link in the PR or something like that).
This should improve the description of the changes, because the contributor will see exactly how his comment affects the list of changes.
In the screenshot below, the line with a yellow background models what the contributor of this PR should see.
As a next step, I suggest checking out the AppImage packaging instructions and pack your generator to an AppImage bundle.
It should copy the original executable and all dependencies (curl/json) into the package.
Also, since your main system is Windows (if I understand correctly), I suggest you use Linux Mint/Ubuntu inside Virtualbox for testing. It should be possible to use WSL, but I haven’t tested it, so you might want to give it a try.
Looks good, my suggestion to add 2 modes (short and full) so the user can test it without github token (I described it here).
Looks like already implemented. Sorry, missed it
I also tried the suggested method using the exported GITHUB_TOKEN environment variable, but it doesn’t work.
We currently use them to group PRs by type when manually writing release notes. That’s all
Yes. You can check first-level dependencies in this script.
There is also a script 1-setup-linux-native.sh which contains the Linux OS dependencies, but there are a lot of second level dependencies (dependency dependencies).
Note that we still use the old AppImage format (v1, not even V2) and it requires to install libfuse2 on newer systems (Fuse 3 only out-of-box) in order to work. @Ahmed-Khaled don’t learn too much the details of this technology yet, it is currently under changes to static libs.
Just assume that it is a kind of self-extracting .zip containing (almost) all the required binaries to work.
I wanted to write a quick hello for my interest in participating in the development of the plugin manager dialogue. My name is Dennis and I am a graduate from the University of Toronto in Canada. Currently, I’m starting to contribute and researching/looking into the community for other things to expand my proposal. Hopefully, I am not too late! Will probably post my ideas later.
Hello @ice0 and @BobSynfig!
Based on your tremendously appreciated replies and guidance, I have done the following
Created a makefile, and added a detailed guide on how to build the script
Read about AppImage (It’s very nice and clean, I am glad I got to know about it)
Packed my script into an AppImage bundle, thoroughly tested it on two Linux distros, and added in the readme a detailed guide on how to use it to run the script on Linux smoothly
Here is the GitHub repo to see the above updates, I would greatly appreciate any feedback you might have!
Since the script is simple, I manually packaged the AppImage, meaning I understood the AppDir structure and created it manually and then I used the appimagetool to create the AppImage,
I am unsure how you package your AppImage, but I expect that you automate this process somehow (From makefiles, etc.)
It would be appreciated If you could let me know how you create your AppImage using the already-made scripts, so I have an idea of what I plan to check in the summer
I am also not sure what the difference is between AppImage v1.0 and v2.0, and If the v1.0 scripts would work with v2.0, I will for sure plan to research this, but If you have an initial idea what the key differences are, it would be greatly appreciated
I am planning to start working on the proposal currently, would you prefer that I create a GitHub issue to get feedback on it, or should I send it here, or PM?
Once again, thank you for your continuous support, I’m looking forward to hearing from you!
The engine is different but both rely on libfuse2. We need the latest version with static libs and fuse3 compatibility.
Some other libs have to be removed also for compatibility with newer Linux.
For differences between v1 and v2, you can find the differences in the specifications.
You will have to read a lot of documentation and specifications in your life of developer.
This point is easy, you don’t need feedback nor to open issues, this is the purpose of documentation.
Thank you very much for the quick response and valuable resources!
I’ll be sure to thoroughly check the resources and read the AppImage documentation and specifications to be able to complete the task successfully, regarding the feedback and issues, I apologize if I wasn’t clear, I was referring to feedback on my GSoC proposal document.
I currently started working on the proposal, and I was wondering If there is a place where I can check previously accepted Synfig GSoC proposals, access to these would offer valuable insights to help me improve my proposal, it would be great if something like this could be provided, but either way, I will do my best to create a quality proposal!
We’ve already received GSoC proposals from some of you, so this is a quick reminder for those who haven’t sent them yet.
Deadline for sending your proposals is April 2 - 18:00 UTC
If you would like to receive feedback, please send a link to your proposal to the project mentor and to me in PM.
P.S. Google docs is preferred, but not required (using Docs, we can add suggestions directly to the proposal).
Hello everyone,
This year I will be participating as a GSoC contributor, I am interested to work on Plugin Manager dialog. I have been using Synfig for over 2 years now, built multiple plugins for Synfig, and created lots of animations. But now as part of GSoC I will making direct contribution to the project, I am interested in building the Plugin Manager dialog. As a Plugin developer myself, I believe I can translate the requirements to proper solution that benefit Plugin Developers as well as end user. I hope my contributions would makes lives of Plugin Developers and Users much easier by simplifying the process of Delivering, Installing and managing plugins in Synfig Studio.
First of all, I want to say that this year we had a lot of amazing participants with strong proposals - it was quite difficult to choose a winner.
We couldn’t make a choice until the last day.
This year we have two project slots and two accepted contributors:
Ahmed Khaled (@Ahmed-Khaled) with the project “Automating Release Notes Generation & Simplifying Linux Download Experience”
Veer Metri (@veermetri05) with the project “Plugin manager dialog”
I want to say thanks to all the applicants who reached us and wish good luck to the accepted contributors as their work on the project is just getting started.
