Skip to content

Updated 2019-08-06

Contributing

Thanks for considering making a contribution to the Allzpark project!

The goal of Allzpark is making film and games productions more fun to work on, for artists and developers alike. Almost every company with any experience working in this field has felt the pain of managing software and versions when all you really want to do is make great pictures. Allzpark can really help with that, and you can really help Allzpark!


Quickstart

Allzpark works out of the Git repository.

git clone https://github.com/mottosso/allzpark.git
cd allzpark
python -m allzpark --demo

Get the up-to-date requirements by having a copy of Allzpark already installed.


Architecture

The front-end is written in Python and Qt.py, and the back-end is bleeding-rez. You are welcome to contribute to either of these projects.

Graphically, the interface is written in standard Qt idioms, like MVC to separate between logic and visuals. The window itself is an instance of QMainWindow, whereby each "tab" is a regular QDockWidget, which is how you can move them around and dock them freely.

User preferences is stored in a QSettings object, including window layout. See view.py:Window.closeEvent() for how that works.


Development

To make changes and/or contribute to Allzpark, here's how to run it from its Git repository.

git clone https://github.com/mottosso/allzpark.git
cd allzpark
python -m allzpark

From here, Python picks up the allzpark package from the current working directory, and everything is set to go. For use with Rez, try this.

# powershell
git clone https://github.com/mottosso/allzpark.git
cd allzpark
. env.ps1
> python -m allzpark

This will ensure a reproducible environment via Rez packages.


Versioning

You typically won't have to manually increment the version of this project.

Major and minor versions are incremented for breaking and new changes respectively, the patch version however is special. It is incremented automatically in correspondance with the current commit number. E.g. commit number 200 yields a patch number of 200. See allzpark/version.py for details.

To see the patch version as you develop, ensure git is available on PATH, as it is used to detect the commit number at launch. Once built and distributed to PyPI, this number is then embedded into the resulting package. See setup.py for details.


Resources

The current icon set is from Haiku.


Guidelines

There are a few ways you can contribute to this project.

  1. Use it and report any issues here
  2. Submit ideas for improvements or new features here
  3. Add or improve this documentation
  4. Help write tests to avoid regressions and help future contributors spot mistakes

Any other thoughts on how you would like to contribute? Let me know.


Documentation

The documentation you are reading right now is hosted in the Allzpark git repository on GitHub, and built with a static site-generator called mkdocs along with a theme called mkdocs-material.

Mkdocs can host the entirety of the website on your local machine, and automatically update whenever you make changes to the Markdown documents. Here's how you can get started.

You can either use Rez and Pipz.

cd allzpark\docs
rez env pipz -- install -r requirements.txt
. serve.ps1

Or install dependencies into your system-wide Python.

cd allzpark\docs
pip install -r requirements.txt
mkdocs serve

cd allzpark/docs
rez env pipz -- install -r requirements.txt
rez env git python mkdocs_material-4.4.0 mkdocs_git_revision_date_plugin==0.1.5 -- mkdocs serve

Or install dependencies into your system-wide Python.

cd allzpark/docs
pip install -r requirements.txt
mkdocs serve

You should see a message about how to browse to the locally hosted documentation in your console.


Guidelines

Things to keep in mind as you contribute to the documentation

  • Windows-first Allzpark is for all platforms, but Windows-users are typically less tech-savvy than Linux and MacOS users and the documentation should reflect that.
  • Try-catch When documenting a series of steps to accomplish a task, start with the minimal ideal case, and then "catch" potential errors afterwards. This helps keep the documentation from branching out too far, and facilitates a cursory skimming of the documentation. See quickstart for an example.