And the answer is … “it depends”.
I’m not too proud of this situation, but …
Dialogue between me and the PO:
– [PO] There’s an icon in the ribbon that gets changed to indicate the user changes exist in the source file and he can synchronize the current timeline with these changes
– [Me] Yes, I’m following you …
[PO] When does this icon change?
-[Me] (puzzled, since I only remember the request ‘this check executes only once per session’) Let me check!
After a few minutes …
– [Me] It depends ..
It actually does not depend, the problem is the code has been written in the “hack it now and get rid of this request” mindset, so even I need a few minutes to completely understand everything that’s happening there and what action triggers what code.
The root problem is the fact the add-in has no internal architecture. It needs:
- a message bus
- a command queue
- an UI state manager
Once they are in place, it’s easy to properly change the icon in the ribbon:
- when a new slide is selected, verify it has a timeline and, if so, if data exists about its synchronization status;
- if no data exists, place a command in a queue that another thread executes
- this command verifies new data is available
- if new data is available, another command is placed in a queue for the UI state manager
- the UI state manager updates the icon in the ribbon
We (I) really need to get out of the “hack this now” mindset.