1. 26 Jan, 2018 1 commit
    • Timm Bäder's avatar
      menu: Guard against NULL toplevel · 136b8853
      Timm Bäder authored
      This can happen, as indicated by GtkMenu explicitly connecting to
      ::destroy of its toplevel window. Do the same thing in GtkComboBox.
      136b8853
  2. 06 Oct, 2017 1 commit
    • Daniel Boles's avatar
      ComboBox: Don’t let modes disconnect each other · 7fc09f18
      Daniel Boles authored
      …from priv->button. My refactor to g_signal_disconnect_by_data()
      included this widget, when I shouldn’t have as both modes use it.
      This e.g. broke opening a CB by keyboard that was currently in menu
      mode, if it had been in list mode initially (e.g. due to the theme).
      
      Fix by moving to disconnect_by_func() and only removing in each mode’s
      destroy() method the signals that it set on the button in its setup().
      
      https://bugzilla.gnome.org/show_bug.cgi?id=788577
      7fc09f18
  3. 05 Oct, 2017 2 commits
  4. 04 Oct, 2017 9 commits
  5. 04 Sep, 2017 1 commit
  6. 01 Sep, 2017 3 commits
  7. 28 Aug, 2017 5 commits
  8. 25 Aug, 2017 1 commit
    • Daniel Boles's avatar
      ComboBox: Use iter before popdown() may invalidate · 696b9a5d
      Daniel Boles authored
      Bad actors, such as our very own FileChooserButton, may connect to the
      :popped-up property and alter the model as the menu becomes in/visible.
      
      We were getting an iter to the model while popped-up, then doing
      popdown(), then using the iter, which may have just been invalidated by
      the errant notify::popped-up handler. If so, we quickly crash fatally.
      
      This is clearly bonkers, but until such patterns are removed, we have to
      work around them. So, set_active() from the clicked item while it is
      known to be valid, by moving the call to set_active() before popdown().
      
      While here, change set_active_iter(iter) to set_active_internal(path) to
      avoid pointlessly going through the iter to get the path we already have
      
      https://bugzilla.gnome.org/show_bug.cgi?id=729651
      696b9a5d
  9. 24 Aug, 2017 1 commit
  10. 23 Feb, 2017 1 commit
  11. 21 Jan, 2017 1 commit
  12. 20 Jan, 2017 2 commits
  13. 19 Jan, 2017 2 commits
    • Daniel Boles's avatar
      combobox: Avoid a pointless assignment · eb26b57c
      Daniel Boles authored
      Don’t get the active item pointer before the grid/non-grid conditional,
      because if we’re in grid mode, we re-get it before selecting it anyway.
      eb26b57c
    • Daniel Boles's avatar
      combobox: Also preselect active item in grid popup · b7cfe3c7
      Daniel Boles authored
      i.e. when wrap-width > 0. This was only being done for non-grid cases.
      So, ComboBoxes in grid mode did not indicate their selection when popped
      up and required users to keynav from ‘nothing’ (at the top-left) to the
      item they wanted to select. By selecting the active item in advance, now
      it’s highlighted & acts as the starting point for keynav around the grid
      b7cfe3c7
  14. 18 Jan, 2017 3 commits
    • Daniel Boles's avatar
      combobox: Work around popup handler altering model · e98e6f73
      Daniel Boles authored
      GtkFileChooserButton installs a handler for the popped-up signal, which
      refilters the menu, in order to hide the “(None)” item from the popup
      if it was previously selected in the ComboBox. This oddity means that:
      
       • Until recently, this item would be selected in the menu shell, which
         would then be popped up and change the selection away from that item.
         This was therefore redundant (more on which below!) but benign.
      
       • After the patch for https://bugzilla.gnome.org/show_bug.cgi?id=771242
         however, this causes a critical assertion fail, as now we stash the
         originally selected item in a pointer so that it can be selected only
         after realisation/popup – but by that stage, the model has just been
         refiltered and the previous pointer no longer refers to a valid item.
      
      This commit works around this problem by, after popping up the menu,
      getting the active item again, in case a popped-up handler has gone and
      invalidated the pointer to the active item that we saved before popup.
      
      If a handler does this, everything done to find/use the original item is
      pointless. But this avoids the ugly critical in FileChooserButton, while
      not harming every other ComboBox that doesn’t mess with its model while
      popping up (hopefully the vast majority), and it’s very difficult to
      imagine a way to check if the active item is /going to/ be hidden later)
      e98e6f73
    • Daniel Boles's avatar
      combobox: Don’t select active item if it’s hidden · dfe89a38
      Daniel Boles authored
      I hope no one ever actually brings such a silly item into this world,
      but this achieves symmetry with the similar checks immediately after.
      dfe89a38
    • Daniel Boles's avatar
      ac4e1625
  15. 01 Dec, 2016 3 commits
  16. 19 Jul, 2016 1 commit
  17. 09 Jun, 2016 1 commit
  18. 28 Apr, 2016 2 commits