At the moment, the cardboard logic swings into action when the view is opened in obsidian. When this happens, cardboard parses the vault to find all the tasks ready to put on whatever boards have been defined. I want to split this parsing (as well as keeping track of edits to files) to a worker which will start when Obisidian launches and run for as long as the application is open. This worker will essentially be a cache of tasks ready to be displayed so when a view is opened it can read from this cache which should lead to faster loading of boards.
However, the main reason for doing this is that it is going to be important for Cardboard to be able to track edits to files so it knows if tasks have moved (due to edits) when it comes to providing drag and drop - as each task is going to have to be associated with a card that appears in (perhaps) multiple columns on (perhaps) multiple boards. If Cardboard is only running when the view is open then it will be blind to changes that happen when it is not open, and this will increase the liklihood of it loosing track of cards and keeping them in their desired order in columns.
There are probably some dragons hidden here (as they say)! I have not explored this - even in thought - yet. Plus I have no idea how to build something which will have 2 separate elm applications in it (as the plugin is written in elm).
At the moment, the cardboard logic swings into action when the view is opened in obsidian. When this happens, cardboard parses the vault to find all the tasks ready to put on whatever boards have been defined. I want to split this parsing (as well as keeping track of edits to files) to a worker which will start when Obisidian launches and run for as long as the application is open. This worker will essentially be a cache of tasks ready to be displayed so when a view is opened it can read from this cache which should lead to faster loading of boards.
However, the main reason for doing this is that it is going to be important for Cardboard to be able to track edits to files so it knows if tasks have moved (due to edits) when it comes to providing drag and drop - as each task is going to have to be associated with a card that appears in (perhaps) multiple columns on (perhaps) multiple boards. If Cardboard is only running when the view is open then it will be blind to changes that happen when it is not open, and this will increase the liklihood of it loosing track of cards and keeping them in their desired order in columns.
There are probably some dragons hidden here (as they say)! I have not explored this - even in thought - yet. Plus I have no idea how to build something which will have 2 separate elm applications in it (as the plugin is written in elm).