1. 12 Sep, 2016 2 commits
  2. 11 Sep, 2016 4 commits
  3. 10 Sep, 2016 3 commits
    • Fran Diéguez's avatar
      Updated Galician translations · 68f43942
      Fran Diéguez authored
      68f43942
    • Michael Catanzaro's avatar
      loginDialog: fix cancel button in ask for username mode · cae4d921
      Michael Catanzaro authored
      If the user clicks Not Listed? to enter ask for username mode, clicks
      cancel, and then attempts to log in via the user list, the user will see
      "Authentication failed" after correctly typing the password, and then
      will become stuck in an empty screen with just the gray noise background.
      
      The problem is, we forgot to disconnect from the signal that's waiting
      for the next button to be pressed on the username entry screen. Since
      the signal handler that executes here is expecting the username to be
      input, and isn't prepared for us to have switched back to user list,
      various bad things happen. We try to start two gdm-password
      conversations at once, for instance, one using the user's password as
      the username. I stopped investigating here, because it's easy to fix by
      disconnecting from the signal at the right time.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=770328
      cae4d921
    • Changwoo Ryu's avatar
      Updated Korean translation · f3362954
      Changwoo Ryu authored
      f3362954
  4. 09 Sep, 2016 5 commits
    • Florian Müllner's avatar
      telepathyClient: Always clear pending messages on destroy · 06d0e7d7
      Florian Müllner authored
      Since commit 82950ece, we acknowledge pending messages when closing a
      chat notification for a channel we are handling to prevent the channel
      from popping up again immediately. While this isn't an issue for channels
      we don't handle, the unread messages of the destroyed notification are
      still considered for the messages indicator in the top bar, which is
      clearly confusing (in particular when we end up showing the indicator
      without any notifications in the list). As it's arguably correct to not
      meddle with a channel handled by someone else, just reset the cache of
      pending messages to address this issue.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=770888
      06d0e7d7
    • Florian Müllner's avatar
      data: Swap default for 'disable-extension-version-check' setting · 5e0e3edc
      Florian Müllner authored
      Nowadays, the user interface has mostly stabilized with most changes
      happening under the hood. As a result, extensions written for previous
      versions of GNOME Shell are very much expected to keep working on
      updates, if it wasn't for the version check that requires a version
      bump in the extension metadata. There has been a setting to disable
      that check for a while, but it's existence isn't widely known (hence
      the common perception that "everything breaks on updates"). While
      there is still some risk that an out-of-date extension can be enabled
      without error, but fails spectacularly later (where we cannot catch
      the exception), it is reasonably small by now when compared to the
      ~95% of extensions that can be "unbroken", so swap the default value
      to disable version checks by default.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=770887
      5e0e3edc
    • Rui Matos's avatar
      windowManager: Fix windows not getting undimmed while hidden · 02a51bfa
      Rui Matos authored
      Mutter's plugin destroy event doesn't happen if a window is hidden
      when it gets unmanaged so we also need to handle the
      MetaWindow::unmanaged signal to check whether the parent should
      dimmed.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=752524
      02a51bfa
    • Rui Matos's avatar
      windowManager: Fix windows not getting undimmed in some cases · dbd04df3
      Rui Matos authored
      meta_window_foreach_transient() iterates through all transients of a
      window, not only direct transients. This means that simply checking if
      a transient is an attached dialog isn't enough because it might be a
      non-direct transient for the window we're checking, in which case we
      don't want to dim the window.
      
      In particular this fixes windows not getting undimmed when they have
      more that one level of transient children and the direct transient gets
      destroyed. In that case we would still find at least one non-direct
      transient child and decide to keep the window dimmed.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=770163
      dbd04df3
    • Arash Mousavi's avatar
      [l10n] update Persian translations · e6adcd99
      Arash Mousavi authored
      e6adcd99
  5. 08 Sep, 2016 5 commits
  6. 07 Sep, 2016 2 commits
  7. 06 Sep, 2016 4 commits
  8. 05 Sep, 2016 2 commits
  9. 04 Sep, 2016 3 commits
  10. 03 Sep, 2016 1 commit
  11. 29 Aug, 2016 1 commit
  12. 28 Aug, 2016 1 commit
  13. 25 Aug, 2016 1 commit
  14. 22 Aug, 2016 4 commits
  15. 21 Aug, 2016 2 commits