# TODOs

 - [ ] Middleware support (FreeRTOS, etc.)
 - [ ] Arduino framework support (needs research to check if it is possible)
 - [ ] Add more checks, for example when updating the project (`generate` command), check for boards matching and so on...
 - [ ] GUI. Tests (research approaches and patterns)
 - [ ] GUI. Reduce number of calls to 'state' (many IO operations)
 - [ ] GUI. Drag and drop the new folder into the app window
 - [ ] GUI. Implement some other methods for Qt abstract models
 - [ ] GUI. Warning on 'Clean' action
 - [ ] GUI. On 'Clean' clean the log too
 - [ ] GUI. Stop the chain of commands if someone drops -1 or an exception
 - [ ] Create VSCode plugin
 - [x] Remove casts to string where we can use path-like objects (related to Python version as new ones receive path-like objects arguments)
 - [ ] We look for some snippets of strings in logs and output for the testing code but we hard-code them and this is not good, probably (e.g. 'DEBUG')
 - [ ] Store a folder initial content in .ini config and ignore it on clean-up process. Allow the user to modify such list (i.e. list of exclusion)
 - [ ] at some point check for all tools (CubeMX, ...) to be present in the system (both CLI and GUI) (global `--check` command (as `--version`), also before execution of the full cycle (no sense to start if some tool doesn't exist))
 - [ ] generate code docs (help user to understand an internal mechanics, e.g. for embedding). Can be uploaded to the GitHub Wiki
 - [ ] colored logs, maybe...
 - [ ] check logging work when embed stm32pio lib in a third-party stuff (no logging setup at all)
 - [ ] merge subprocess pipes to one where suitable (i.e. `stdout` and `stderr`)
 - [ ] redirect subprocess pipes to `DEVNULL` where suitable to suppress output (tests)
 - [ ] Two words about a synchronous nature of the lib and user's responsibility of async wrapping (if needed). Also, maybe migrate to async/await approach in the future
 - [ ] `__init__`' `parameters` dict argument schema (Python 3.8 feature).
 - [ ] See https://docs.python.org/3/howto/logging-cookbook.html#context-info to maybe remade current logging schema (current is, perhaps, a cause of the strange error while testing (in the logging thread))
 - [ ] UML diagrams (core, GUI back- and front-ends)
 - [ ] CI is possible (Arch's AUR has the STM32CubeMX package, also there is a direct link). Deploy Docker in Azure Pipelines, basic at Travis CI
 - [ ] Test preserving user files and folders on regeneration and mb other operations
 - [ ] Move special formatters inside the library. It is an implementation detail actually that we use subprocesses and so on
 - [ ] Mb store the last occurred exception traceback in .ini file and show on some CLI command (so we don't necessarily need to turn on the verbose mode). And, in general, we should show the error reason right off
 - [ ] 'verbose' and 'non-verbose' tests as `subTest` (also `should_log_error_...`)
 - [ ] the lib sometimes raising, sometimes returning the code and it is not consistent. While the reasons behind such behaviour are clear, would be great to always return a result code and raise the exceptions in the outer scope, if there is need to
