1. 13 Nov, 2017 3 commits
  2. 11 Nov, 2017 1 commit
  3. 10 Nov, 2017 2 commits
  4. 09 Nov, 2017 4 commits
  5. 07 Nov, 2017 1 commit
    • Kalev Lember's avatar
      updates page: Fix flatpak updates inadvertently triggering a reboot · d40a2129
      Kalev Lember authored
      Move the logic to decide if we need to reboot or not to run _before_
      scheduling an update. Previously we would do it _after_ having applied
      the updates, which didn't work because the app flags we were looking at
      to make the decision (AS_APP_STATE_UPDATABLE_LIVE) had already changed
      at that point (to AS_APP_STATE_INSTALLED).
      
      This fixes a long standing bug where flatpak updates done through
      "Update All" would inadvertently bring up the shell reboot dialog and
      then lead to a gnome-software crash after dismissing the dialog.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=782618
      d40a2129
  6. 06 Nov, 2017 3 commits
  7. 05 Nov, 2017 1 commit
  8. 04 Nov, 2017 1 commit
  9. 02 Nov, 2017 4 commits
    • Joaquim Rocha's avatar
      plugin-loader: Allow the whole generic updates operation to be cancelled · ec11d659
      Joaquim Rocha authored
      This patch makes use of the generic cancellable object passed to the
      function that performs the generic updates and cancels the whole
      operation.
      
      This functionality is not reflected in the UI yet but we should have a
      button for aborting the "update all" operation. And when that happens we
      simply need it to cancel the cancellable object mentioned above.
      ec11d659
    • Joaquim Rocha's avatar
      plugin-loader: Use the apps' cancellable when doing a generic update · a3077f60
      Joaquim Rocha authored
      This way users will be able to cancel the updates from the apps' pages.
      a3077f60
    • Joaquim Rocha's avatar
      Allow to cancel app ops in the details view that were started elsewhere · 7264d345
      Joaquim Rocha authored
      The cancellation of app related operations has been tied to each view
      individually. E.g. if an app update is started from the updates page and
      the user goes to that app's details page, even though there is a cancel
      button showing, it won't do anything because it's cancellable object is
      not the one with which the update operation was started.
      
      Now that each app has a cancellable object, this patch makes use of that
      to ensure that any operations related to the app are cancellable even if
      they were started from a different page.
      7264d345
    • Joaquim Rocha's avatar
      Add a cancellable to GsApp objects · da83bd73
      Joaquim Rocha authored
      This cancellable should be used in operations related to the app, e.g.
      installing, updating, etc. This is convenient because sometimes an
      operation will be shown in different views, so we cannot use a local
      cancellable, as it will be impossible to start the operation in one view
      and cancel it in another.
      da83bd73
  10. 31 Oct, 2017 1 commit
  11. 30 Oct, 2017 4 commits
  12. 28 Oct, 2017 1 commit
  13. 27 Oct, 2017 5 commits
  14. 26 Oct, 2017 3 commits
  15. 25 Oct, 2017 1 commit
    • Kalev Lember's avatar
      Don't error out for over 500 results · e770c15a
      Kalev Lember authored
      We can legitimately get more than 500 when updating a large number of packages
      and then showing the offline update results.
      
      This commit drops the failure path for >500 results; for cases where
      performance is critical (search), the results are already truncated in
      gs_plugin_loader_job_sorted_truncation_again() and for other cases we
      can just keep on going.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1496489
      e770c15a
  16. 24 Oct, 2017 2 commits
  17. 21 Oct, 2017 1 commit
  18. 19 Oct, 2017 2 commits