-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Working implementation of local backend stored data #23
Conversation
…en through the settings panel. Added a settings theme for better contrast, other backend solutions could be chosen here including input fields to set up the necessary connection strings.
…gs locally in a config file and secondly local_storage.gd that manages to save all data locally through custom resources. Both board.gd and boards.gd scripts needed some minor changes to deal with a local backend since some featrues are not implemented (user management and public boards)
… is emited on line 84 to update the board so cards switching lists can be updated and saved locally. Some methods were rearranged to navigate easier methods that affect the same object eg. boards lists and cards. An if statement was needed in the update_card method to deal with loading cards as resources that would trigger an error because as first items to be loaded they would find an existing list or board. Added a method _on_list_dropped that is planned to deal with lists being swapped in the interface, atm they are only visually working but there is no position data available yet.
…r a way to store all data locally. Added default values necessary in the _init method to load saved resources. Exported all variables needed to be saved as resource.
…e so it is easier traceable in the editor.
Updated license for this project that supports a local backend.
…order changes to the local backend The new method _on_list_order_update first clears the existing active_board.lists, then appends the new lists in order to the active_board.lists
…nto backend_local
…mically loaded through the app_global singleton. This forces to only have one backend solution loaded at all times.
…g the backend module to be loaded dynamically.
…r the card order system to. Added the new order_signal for cards in the _on_card_dropped method so the order can be saved locally. Rewrote the _on_list_order_update to _on_order_update and it will save the new ordered array on their respective board.lists or list.cards array.
…to the ELIXIR backend.
# Conflicts: # scripts/data_repository.gd # scripts/models/board_model.gd # scripts/scene_utils.gd all resolved using remote master
…or msg + error code
…rchived card, added a condition to test if card is archived
…t although UUIDs are strings.
@CptFubar I'll be back to the project soon and then finally review your PR! |
@CptFubar I'm so bad at managing my 10.000 personal projects, sorry for leaving this hanging. I'll try to review it soon! It almost looks like my previous comment, but I'll see if this time I finally give it attention. |
Doing some house keeping, i am closing this pull request since it does not fix a bug or is any important feature. |
Re-opening to merge it. Again, sorry for not answering earlier - I wrangle between way too many projects. |
Thanks a lot for the contribution! This is great. I'm updating the README with the new option for the local storage. |
Unfortunately, after further testing I found a breaking bug with this implementation, see #28. In any case, I left the local backend implementation in its own branch, since it adds a lot of value (until me or someone fixes #28, then I'll merge it into master). |
After merging my local_backend branch into master i resolved the conflicts that occurred because of my badly implemented error handling implementation by using all origin master files instead of local.
Non the less, i had updated the error handling a while back to use push_error method instead of just a prints statement to appear in the logs, this way they are logged in the log file and are helpful in debugging inside the Godot editor and debug window.
This branch features a new login screen that offers a rudimentary backend choice that can be further expanded into a detailed configuration of the implemented backends eg. connection strings to existing servers, multiple local accounts etc.
Another implemented feature is a local config file that stores all the settings options and is loaded upon starting the app.
It is implemented through a new singleton class "app_manager" that manages the applications configuration and startup values.