Developer guide

This project is not even close to what I want it to be. I'd like like to invite anyone to be part of the development. Generally this is pretty straight forward: Fork the repository, push your (tested) changes to the fork and finally send a pull request. There may occur tons of problems, but covering all of them would go beyond the scope of this wiki. Contact me in case of problems.

How to contribute

If you wish to contribute you are free to do so. Due to problems in the past I tend to be strict about this.

###For extensions:

1. Do not implement stuff and send a PR!
2. Open an issue.
3. Make clear that you are willing to work on the issue.
4. Create an extension.
5. Send a PR to the branch of the milestone the issue is assigned to.
6. Be happy about the pull.

###For changes to the core:

1. Do absolutely not implement stuff and send a PR! In 99,9% of the cases it will be rejected.
2. Open an issue.
3. Discuss if the issue is reasonable. Use IRC if it has to be interactive.
4. Discuss and find the most suitable and best designed approach to implement.
5. Make clear that you are willing to work on the issue.
6. Work on the issue.
7. Reflect on the implementation. If you have doubts it fulfills 4 go back to 3.
8. Test it. Not realworld testing, but use it a few days yourself.
9. Send a PR to the branch of the milestone the issue is assigned to.
10. Be happy about the pull.

This way I will be notified we can talk about it and nobody will be angry because its PR has been rejected. Further there will not be several people working on the same issue. I really hate to reject pull requests, but according to the goals, I can only accept code that is well designed, documented, clear, and readable etc. My requirements are not even close to those of syncthing, but every time I reject a pull request I think of this.

If you are willing to contribute, but have no clue what to do, check the state of the project. There is plenty of other things you can do aside from coding: Check and extend the wiki, test the applications and report issues, check the issues and try to help debugging and whatever you think you could do to make albert better.

One common problem is bugtracking on remote problems. I estimate this to be over 95% of the time spent to fix a reported bug. You could volunteer to just find the exact technical problem poeple report in their issues. E.g. by checking peoples coredump or reproducing their issue and finding the malicius code. You would not even have to code. Just contact me.

How to create extensions

1. Copy the template extension using the script.
2. Adjust the values in metadata.json and CmakeLists.txt.
3. Adjust the extension to your liking. Check the extension interface for members that you may or must implement.

Pretty easy, however there are some caveats: Your extension must have a unique id; set it in metadata.json. To keep the code readable the main class of the extension is called Extension and if the extension returns a configuration widget it shall be called ConfigWidget. This is not strictly necessary, your code will run either way, but the intention is to unify the filenames of the plugins. This would implicitly lead to naming conflicts, therefor all classes of an extensions live in a dedicated namespace. Remember to define the namespace in the *.ui files, too. Thats it.