1. 17 Apr, 2018 2 commits
  2. 29 Mar, 2018 1 commit
  3. 23 Mar, 2018 1 commit
  4. 14 Mar, 2018 1 commit
  5. 05 Mar, 2018 1 commit
  6. 01 Mar, 2018 2 commits
  7. 28 Feb, 2018 1 commit
  8. 27 Feb, 2018 1 commit
    • Joaquim Rocha's avatar
      Notify apps' property changes from the main loop · 176cb24b
      Joaquim Rocha authored
      These changes avoid a race when apps are refined from within a
      different thread, as their properties' notification were being
      emitted (and thus triggering) code from those.
      Specifically there was a race when setting up the CSS for the
      background tile as this code was not getting run from the main
  9. 26 Feb, 2018 1 commit
  10. 23 Feb, 2018 3 commits
  11. 22 Feb, 2018 2 commits
  12. 19 Feb, 2018 1 commit
  13. 15 Feb, 2018 1 commit
  14. 31 Jan, 2018 1 commit
  15. 27 Jan, 2018 1 commit
    • Kalev Lember's avatar
      plugin loader: Slightly increase warning timeouts · c01aa5c8
      Kalev Lember authored
      Instead of 0.5 seconds, warn when a plugin takes longer than 1 second to
      run. We've had this warning for the appstream plugin for a while now
      during startup and it's just noise, hindering debugging / breaking in
      gdb on g_warnings.
  16. 25 Jan, 2018 4 commits
    • Joaquim Rocha's avatar
      Make the QUEUED_FOR_INSTALL UX consistent with having a pending-action · fdf5bc2e
      Joaquim Rocha authored
      Apps can get assigned an AS_APP_STATE_QUEUED_FOR_INSTALL state which
      means they will not be installed until the network is connected again.
      The UX for showing this state in the details page consisted in showin a
      "Pending" string and a cancel button.
      This is very similar to the UX of the apps when they have a
      pending-action assigned to them, but actually less informative.
      Thus, for consistency and improvement, these changes make the UX for the
      QUEUED_FOR_INSTALL state the same as for pending-action.
    • Joaquim Rocha's avatar
      Limit the number of certain operations running in parallel · 199acf85
      Joaquim Rocha authored
      Operations like installation/update/upgrade-download can be resource
      intensive in slower machines, e.g. several installs at the same time may
      use memory or disk to a point where the whole system becomes unusable.
      This has been observed on machines that have 2GB of RAM (or less) and
      spinning disks.
      To avoid such situations, these changes limit the number of operations
      that can run in parallel by using a thread pool. The number of parallel
      operations allowed is in function of the RAM (one thread allowed per
    • Joaquim Rocha's avatar
      Add a pending-action to GsApp · b59516e3
      Joaquim Rocha authored
      Sometimes we cannot apply an action to a GsApp right away (e.g. because
      of not having an available worker thread for the action), so we should
      be able to set up an internal state in GsApp objects in order to reflect
      For that purpose, this patch introduces a gs_app_get/set_pending_action
      private method that can be used to track and eventually inform the user
      about this condition.
    • Joaquim Rocha's avatar
      Don't recover the apps' state back to QUEUED_FOR_INSTALL · f762cd2f
      Joaquim Rocha authored
      The AS_APP_STATE_QUEUED_FOR_INSTALL is a state that depends on usually
      temporary conditions, like not having a connection. So we shouldn't
      recover that state, otherwise, the following can happen:
      * there's no connection so an app gets queued for installation;
      * when the connection becomes available the app starts installing;
      * however if the user cancels the installation, the app will show up as
        queued for install.
      Thus, this patch prevents the mentioned state from being recovered.
  17. 12 Jan, 2018 2 commits
  18. 11 Jan, 2018 1 commit
    • Kalev Lember's avatar
      GsApp: Avoid dereferencing priv before g_return_if_fail checks · 53d502da
      Kalev Lember authored
      We had a common pattern throughout the file to do:
        GsAppPrivate *priv = gs_app_get_instance_private (app);
        g_autoptr(GMutexLocker) locker = g_mutex_locker_new (&priv->mutex);
        g_return_if_fail (GS_IS_APP (app));
      ... which led to crashes when app was NULL, as g_return_if_fail was
      never reached in that case. This commit reorders this so that we first
      do the g_return_if_fail check and only then dereference priv.
  19. 10 Jan, 2018 3 commits
    • Joaquim Rocha's avatar
      Change how apps are queued for installation · 22ea48b1
      Joaquim Rocha authored
      When installing an app in g-s while it is offline, g-s was adding it to
      the pending installation queue directly. However, if the app is coming
      from a local source like a local repository (USB drive, test repo, etc.)
      that behavior is not ideal. So it should be up to the plugins whether an
      app installation is performed or queued for later.
      To achieve that, this patch changes how the plugin-loader behaves by
      allowing plugins to check the state of the network themselves themselves
      (by introducing a new method gs_plugin_get_available_network), and
      checking the state of apps after calling the gs_plugin_app_install
      methods are called: if the app's state is QUEUED_FOR_INSTALL, then it
      adds the app to the installation queue.
      This means that in order to keep supporting this behavior in their
      platforms, plugins need to check whether apps should be queued for
      installation, set the mentioned state to them, and return TRUE (in
      the app install override).
      This patch changes that already for the PackageKit and Flatpak plugins.
    • Kalev Lember's avatar
      trivial: Fix a typo · cb7fca19
      Kalev Lember authored
    • Kalev Lember's avatar
      plugin loader: Fix a crash in gs_plugin_loader_helper_free · 0c0e6b22
      Kalev Lember authored
      Don't unconditionally dereference an app associated with a plugin job,
      without checking first that it's non-NULL.
  20. 03 Jan, 2018 2 commits
  21. 02 Jan, 2018 4 commits
  22. 20 Dec, 2017 1 commit
  23. 08 Dec, 2017 3 commits