Right now the global classes like ItemManager and CollectionManager don't do a very good job of enforcing the various invariants that should be asserted in the application. For example, if the current active item is a collection then it should be the same as the current active collection. Things like these are left to the rest of the code, and it is easy to make a mistake in keeping these two classes in sync.

I think we should consider merging them together, so that it becomes harder to violate these conditions.

Second, the state transitions are very racy. Eg., if a user clicks on a new collection, then the ItemManager and CollectionManager will be updated in two separate steps, and each step will emit an active-changed. In between these two signal emissions the application will be in an incoherent state.

Another example is this code to move back from the preview:

static void
photos_main_toolbar_back_button_clicked (PhotosMainToolbar *self)
{
  PhotosMainToolbarPrivate *priv = self->priv;

  photos_base_manager_set_active_object (priv->item_mngr, NULL);
  photos_mode_controller_go_back (priv->mode_cntrlr);
}

The first line emits ItemManager:active-change and the second emits ModeController:window-mode-changed. In between these two the application will have (active_item = NULL, mode = PREVIEW), and depending on how the rest of the code reacts to these signals, they need to handle these transitional states carefully.

The history here is that the code started as a clone of gnome-documents which used to be a single view application. The current split view designs have more sophisticated interactions, so a more declarative approach makes it simpler to introduce changes in the application. Currently it is very easy for an unrelated change to introduce a regression.