1. 08 Sep, 2017 9 commits
  2. 07 Sep, 2017 4 commits
  3. 06 Sep, 2017 9 commits
  4. 05 Sep, 2017 13 commits
  5. 04 Sep, 2017 5 commits
    • Iñigo Martínez's avatar
    • Iñigo Martínez's avatar
    • Debarshi Ray's avatar
      Consolidate code to update MainToolbar on ItemManager::items-changed · 93fe8275
      Debarshi Ray authored
      Most GActions are enabled/disabled in photos_application_actions_update
      when there is a state change. Now that the selection mode is backed by
      a GAction, there is no reason to directly enable/disable the GtkButton
      when the number of BaseItems change.
      This also disables all the other app.search-* and app.selection-*
      GActions when there are no BaseItems in the current mode.
    • Debarshi Ray's avatar
      embed: Don't keep the searchbar active merely because it has the focus · b40e16e3
      Debarshi Ray authored
      The searchbar shouldn't get yanked out (or hidden) when the user is
      actively changing the search constraints, but that's not the same as
      having the focus. The searchbar might still be focused when the user
      is using the GtkStackSwitcher to change the modes.
      Fallout from 77036628
    • Debarshi Ray's avatar
      Simplify Searchbar handling and don't show it on key presses in PREVIEW · 9b2d8cd8
      Debarshi Ray authored
      Whenever the selection or window modes changed, if the app.search
      GAction's state was FALSE, the Searchbar used to be removed from the
      MainToolbar. It would be added back if the new mode supported search.
      The photos_searchbar_handle_event method used the presence of a parent
      container to decide whether it's supposed to handle keyboard events
      for a given mode.
      This hinges on the app.search GAction having the right state before the
      MainToolbar handles the mode change. However, that's not the case when
      going from SEARCH (without an active collection) to PREVIEW. The
      GAction is toggled in photos_embed_prepare_for_preview when the search
      state is saved. That's after the application has entered PREVIEW.
      Therefore, pressing a key when previewing a search result will show the
      Searchbar, which it is not supposed to.
      The second problem arises if the Searchbar is removed and added while
      it was animating away. It shows a grey bar, without any entry, once it
      is added back to the MainToolbar. Supposedly the remove/add cycle in
      the middle of the animation confuses GTK+.
      This isn't observed in practice because commit 77036628
      prevents the Searchbar from being hidden during mode changes. It's
      only hidden when viewing a collection, which doesn't use the same code
      path as selection or window mode changes. However, that's going to be
      a problem once the faulty behaviour introduced by commit
      77036628 is fixed in a subsequent patch.
      All that can be addressed, and the code simplified, if the Searchbar is
      never removed from MainToolbar. Instead of relying on the presence of a
      parent, it can use the GAction's enabled property to decide whether to
      handle keyboard events or not.
      As a result, this reverts commit fa26cf48 and keeps the code in
      sync with gnome-documents.