Ene architecture issues

[MaT1g3R]

I am not happy with the architecture of Ene at this moment. We are at a point that the application is not a prototype anymore and we need to carefully think about this before adding on more features without thinking. Besides poor code quality in general in cases such as this and this, the code architecture also needs to be reworked. Here's a non-exhaustive list of examples that reflects the problems:

• Unit tests writing to disk:

  • https://github.com/EneApp/Ene/blob/master/tests/test_get_resources.py
  • https://github.com/EneApp/Ene/blob/master/tests/test_files.py

• Bushiness logic mixed with database access:

  • https://github.com/EneApp/Ene/blob/master/ene/files.py#L54
  • https://github.com/EneApp/Ene/blob/master/ene/files.py#L194

• Configuration logic mixed with UI:

  • https://github.com/EneApp/Ene/blob/master/ene/ui/settings_window.py

• Not using dependency injection and creating object in __init__ methods:

  • https://github.com/EneApp/Ene/blob/master/ene/files.py#L40
  • https://github.com/EneApp/Ene/blob/master/ene/ui/main_window.py#L53

• Classes knowing about raw file paths when they really shouldn't:

  • https://github.com/EneApp/Ene/blob/master/ene/api/media.py#L31

What needs to happen, in order:

1. There will be no additional features added to Ene before the architecture issues are addressed.
2. asyncio branch must be merged to master before we address any of these issues, otherwise it will just lead to merge conflicts.
3. @MaT1g3R and @jsedge needs to read this blog post and watch this talk
4. We need to clearly define the set of layers of our application, and the APIs that they provide.
5. Refactor the code to reflect the reworked design.

Why are we doing this?

If we do not address this issue now, it will be hard for us to test and add additional features to our application. This will bite us in the ass in the future.

[MaT1g3R]

Both quamash and asyncqt seems to be dead, asyncio is not happening