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.