1. 14 Mar, 2021 1 commit
  2. 08 Mar, 2021 1 commit
  3. 07 Mar, 2021 1 commit
  4. 04 Mar, 2021 1 commit
  5. 03 Mar, 2021 1 commit
  6. 02 Mar, 2021 1 commit
  7. 22 Jan, 2021 1 commit
  8. 22 Oct, 2020 1 commit
  9. 01 Sep, 2020 2 commits
  10. 18 Jun, 2020 2 commits
  11. 17 Jun, 2020 2 commits
  12. 11 Jun, 2020 1 commit
  13. 09 Jun, 2020 1 commit
  14. 31 May, 2020 1 commit
  15. 08 May, 2020 2 commits
  16. 22 Apr, 2020 2 commits
  17. 28 Mar, 2020 2 commits
  18. 05 Nov, 2019 2 commits
  19. 20 Oct, 2019 1 commit
  20. 19 Sep, 2019 1 commit
  21. 12 Aug, 2019 1 commit
  22. 06 Aug, 2019 1 commit
  23. 05 Aug, 2019 1 commit
  24. 04 Aug, 2019 1 commit
  25. 31 Jul, 2019 2 commits
  26. 24 Jul, 2019 1 commit
  27. 13 Jul, 2019 1 commit
    • Nate Graham's avatar
      Make "Updates Available" notification persistent but low priority · b9bf6a37
      Nate Graham authored
      Summary:
      Discover's "Updates are available" notification currently suffers from some problems:
      1. With the default timeout, it disappears quickly and is likely to be missed
      2. After timing out, it appears in thie history, where is is both redundant (because the Update Notifier system tray icon has become visible) and also useless (because it can't be interacted with due to https://bugs.kde.org/show_bug.cgi?id=407361 and https://bugs.kde.org/show_bug.cgi?id=407667)
      3. Once updates are performed, the notification in the history sticks around uselessly because notifications can't be revoked once they're in the history (See https://bugs.kde.org/show_bug.cgi?id=409323#c3)
      
      This patch fixes those issues by making the update persistent but low priority.
      
      This means it must be noticed by the user and interacted with in some way before it
      disappears from the screen--either by dismissing it or running the updates. But once
      dismissed, it's gone forever, and doesn't clutter up your history.
      
      BUG: 409757
      BUG: 409331
      FIXED-IN: 5.17.0
      
      Test Plan:
      1. Have updates available
      2. Deploy patch
      3. Restart plasmashell
      4. See that the notification is now persistent
      5. Dismiss notification
      6. See that it no longer clogs up the history
      7. Restart plasmashell again
      8. Click on the notification's body or "Update" button
      9. See that Discover opens and the notification disappears
      
      Reviewers: apol, #discover_software_store
      
      Reviewed By: apol, #discover_software_store
      
      Subscribers: plasma-devel
      
      Tags: #plasma
      
      Differential Revision: https://phabricator.kde.org/D22429
      b9bf6a37
  28. 03 Jun, 2019 1 commit
  29. 22 May, 2019 1 commit
  30. 30 Apr, 2019 2 commits
    • Kai Uwe Broulik's avatar
      Add DesktopEntry to notifyrc · b2a35f5a
      Kai Uwe Broulik authored
      This allows the new notification KCM to identify Discover as an application.
      While technically the updater isn't "Discover", it is as far as the user is concerned.
      If the entry were "System Updates" I would have kept them under Services but since this explicitly says "Discover" which the user should
      know is for installing and updating things, moving "Discover" under the application settings makes sense.
      
      Differential Revision: https://phabricator.kde.org/D20919
      b2a35f5a
    • Script Kiddy's avatar
      SVN_SILENT made messages (.desktop file) - always resolve ours · c09eaa85
      Script Kiddy authored
      In case of conflict in i18n, keep the version of the branch "ours"
      To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
      c09eaa85
  31. 21 Feb, 2019 1 commit