-
Debarshi Ray authored
The legal ways to request a state change are now clearer and stricter than before: - You cannot move to the preview directly. You must set a non-NULL active item to do that. - You cannot set a NULL active item to go back from the preview. You must use the go_back method for that. We assert pre and post conditions for state transitions to enforce these rules and catch programmer errors. Earlier, the mode would be updated after "load-started" was emitted. That is no longer the case. Signals are emitted only after the state change is complete. So adjust accordingly. Stop abusing "load-started" to do things that should be performed in the "window-mode-changed" handler. ie. code that should not be run while navigating within the preview. Untangle and consolidate the search save and restore logic. Instead of using hard to read and racy conditions in a PhotosItemManager::active-changed handler, we have now split it into the "window-mode-changed" and "active-collection-changed" handlers. This is much easier to read and understand. The logic to relax the search criteria when viewing a collection has now been moved to PhotosEmbed from PhotosOverviewSearchbar. Otherwise, the "active-collection-changed" handlers in these two classes would stomp on each other. Even though the state represented by these two classes are tightly coupled (preview must have an active item, and you can't be in overview with an active item, etc.), ItemManager sounds like a misnomer for the purposes served by the ModeController. Due to my inability to think of a better name, the ModeController type is now an alias for ItemManager and we have retained the method names. https://bugzilla.gnome.org/show_bug.cgi?id=737071
ee3a5edb