Decide how to move forward with the python version

[phillipberndt]

There are currently two versions of autorandr around due to the difficulties with #7.

The Python version has some advantages over the bash version. That is naturally the case, because in Python we can pass around objects without having to serialize everything all the time. Unique features are solutions to #8, #9, reduced configurations that only store non-default settings with autorandr.py setting the values upon loading of the profiles, support for reflection & gamma values, and of course improved speed because it does not need to call awk, sed, md5sum and so on. I therefore won't just throw that code away.

On the other hand, the bash version obviously needs maintenance as well.

I'll have to decide whether to separate both versions into their own repositories, which one to promote to the version I primarily concerned myself with, and whether to choose a different name for the rewrite.

[bcremer]

1+ for only maintaining one version.

I tend to favour the python version if it stays a single, self contained file.

I don't like to mess around with easy_install, pip or my distributions package manager to get this script running.

[phillipberndt]

I'm not a fan of superflous complexity, so yes, it will stay a single file. With your feedback, @tachylatus comment that he'd continue to contribute to a Python version in #8 and the momentum it gained with @RasmusWL's latest additions, I believe it's best to stick to the Python script.

Here's what I'm going to do, unless someone objects here:

• Move the bash autorandr into a legacy branch in this repository (both aur and portage support branches, so packaging that version shouldn't be a problem) and update the pull-request in the upstream repository to pull from that branch accordingly
• Adjust the Makefile to install autorandr.py as autorandr
• But do not remove the extension from autorandr.py to allow easy merging/separation of the different versions and to alert maintainers to the change (for example, this ebuild will break).
• Update the Readme, of course
• I'll only write new code for the Python version
• I'll continue to fix bugs as issue reports come in for the Bash version
• I'll continue to pull merge requests for the legacy branch
• If ever a incompatibility should be introduced, I'll add a warning to the bash version
• If someone does not wish to go with the Python version and would maintain the Bash version himself, I'll replace the contents of the legacy branch with a message pointing to the new location / add a link to the master branch'es README on request, and will completely remove that branch after some time

[bcremer]

Sounds all reasonable to me. +1

[phillipberndt]

Since no one complained, I went through with this.

[sparr]

the bash version obviously needs maintenance as well.

why?