RodneyBaker
commented
2 years ago Closed RodneyBaker closed 1 year ago
RodneyBaker
commented
2 years ago RodneyBaker
commented
2 years ago Reports (Issues) Link: https://github.com/opentoonz/opentoonz/issues
Open Questions: Link: https://github.com/opentoonz/opentoonz/issues?q=is%3Aissue+is%3Aopen+label%3Aquestion
RodneyBaker
commented
2 years ago RodneyBaker
commented
2 years ago Documentation Link: https://opentoonz.readthedocs.io/en/latest/
RodneyBaker
commented
2 years ago Translations
RodneyBaker
commented
2 years ago Roadmap Link: https://github.com/opentoonz/opentoonz/labels/roadmap
Disclaimer: Roadmapping for Opentoonz is currently not a process that is locked down. In general the following will tend to cause a feature request or bugfix to be labeled with 'roadmap':
Roadmapping is no guarantee of implementation but is an indicator that progress (however incremental) is steadily being made toward that goal.
RodneyBaker
commented
2 years ago Development
Discussion: https://github.com/opentoonz/opentoonz/issues/2746
(The pertinent section of @shun-iwasawa's post is re-presented here)
Basic policy for development of OpenToonz so that other members can review and merge more PRs without hesitating.
The policy consists of one principle and two supplementary notes:
PR can be merged if it will not interfere existing usages. note, however, that
If there is the possibility that introducing PR may conflict OT's existing license, please wait for owner's review. From several month before releasing stable release date (to be announced), please do not merge "feature PR"s. OT has many features which enables various way of producing animation. A modification for some workflow may become disadvantage for others. In such case please consider to make it optional (via user profiles) so that users can select whether to use it.
Here are examples:
Bugfix : Fine to be merged.
Refactoring : Fine to be merged.
Enhancement / Speed-up : Fine to be merged.
Translation : Fine to be merged.
New Fx : Fine to be merged.
New command : Fine to be merged.
New panel : Fine to be merged.
New preset (fx, camera settings, shortcut, etc.) : Fine to be merged.
Altering default user profiles (preferences, panel layout and shortcut) : Fine to be merged.
Altering UI which cannot be controlled user profiles (like adding buttons to the panel or adding commands to the context menu) : Basically it's fine to be merged, but please be careful if it will not disturb the conventional usage.
Altering existing fx or rendering behavior : Basically it's fine to be merged, but please ensure that it will not change a rendering result of a scene which is made with the previous version.
As always, any contributions are much appreciated. Please let me know if there are any opinions or questions to the above.
Thanks!
RodneyBaker
commented
2 years ago Bulding Opentoonz (locally)**: Link: https://github.com/opentoonz/opentoonz#how-to-build-locally
**Note that these instructions need to be updated/streamlined but the process as written should work.
RodneyBaker
commented
2 years ago Reporters
age3rcm
commented
2 years ago for the future of opentoonz, i wish more people use it for projects with cut-out character rigs i have made with my knowledge a rig based on what i learned from the DHX studios asset leaks of adobe flash project files, but with some improvements i thought would be nice to haves. the project on gumroad did hit 220 unique downloads for it, and i believe most of them are people interested to know if opentoonz can handle a cut-out rig just like adobe flash can and i believe that some changes to the workflow, mimicking adobe flash, would make it even more desirable and attractive to give cut-out rigs a solid structure for opentoonz to be adopted
i plan to make quick animation projects with these rigs and release the source files for free for people to inspect but i confess, i did not really make a "full" animation with opentoonz yet to know more about opentoonz workflow and learn precisely what it could improve compared to adobe flash or toonboom harmony
RodneyBaker
commented
2 years ago Updating Documentation There are a number of areas we should update related to documentation. While there is user documentation (See Post and Link above), specifically here I refer to development documentation. This includes ensuring building and testing documentation is as current as possible but also information and instructions for users, user-developers and developers contributing to Opentoonz. Here is one example:
Two things that should be reviewed related to this feature request instruction:
Here I assume that the Opentoonz community currently prefers feature requests being submitted to github. This does need to be reviewed however as many developers have expressed they prefer feature requests be separate from bug and crash reports. The original Google Groups (available now in the original English as well as Japanese and Spanish flavors) are still active although not used as frequently as Github for submitting requests. The assumption is that Github requests are expected to be in English and if that is the case the Google Groups still provide a very useful venue for users.
Updates to documentation for the Opentoonz Github repository can be submitted at any time. Simply make the edit and submit a PR to initiate the change.
Opentoonz user documentation relies on a separate dedicated repo. Link: https://github.com/opentoonz/opentoonz_docs
RodneyBaker
commented
1 year ago This is linked above but wanting to start the year with a focus on bug hunting...
https://github.com/opentoonz/opentoonz/issues?q=is%3Aissue+is%3Aopen+label%3Abug
For those with interest there is much you can do without writing a single line of code. Some bug reports simply need to be validated as current and any insight into a problem will help in working toward its solution.
Thanks!
RodneyBaker
commented
1 year ago Reports specifically labeled as related to Linux OS:
https://github.com/opentoonz/opentoonz/issues?q=is%3Aissue+is%3Aopen+label%3Aos-linux
RodneyBaker
commented
1 year ago Reports specifically labeled as relating to Mac OS:
https://github.com/opentoonz/opentoonz/issues?q=is%3Aopen+is%3Aissue+label%3Aos-mac
(As of the time of this writing) We are half way to the release of v1.7.
GENERAL INFORMATION Current Pull Requests: https://github.com/opentoonz/opentoonz/pulls
Nightlies: (Currently experiencing issues) Link: https://github.com/opentoonz/opentoonz_nightlies/releases
Automated builds**:
https://github.com/opentoonz/opentoonz/actions
**Automated builds are useful within specific contexts. In general they incorporate the code changes from the current PR on top of the code that is current in the last nightly build. They will not include the code of other PRs that have not been merged into the nightly builds.
Note that there are two primary ways these automated builds create their working artifacts; via appeyor and via github actions. both can be ran as portable releases (on WIndows) but note that builds generated with appveyor require a manual renaming of the stuff directory (as 'portablestuff' and placement inside the root opentoonz directory of the artifact. This is required to ensure any changes to user interface get used when running the program.