1. 03 Jul, 2020 2 commits
  2. 02 Jul, 2020 1 commit
  3. 01 Jul, 2020 3 commits
  4. 30 Jun, 2020 11 commits
  5. 28 Jun, 2020 1 commit
  6. 25 Jun, 2020 1 commit
  7. 22 Jun, 2020 1 commit
  8. 21 Jun, 2020 1 commit
  9. 18 Jun, 2020 2 commits
  10. 17 Jun, 2020 6 commits
  11. 15 Jun, 2020 2 commits
    • Philip Withnall's avatar
      gs-app-row: Coalesce refresh operations where possible · 4a12e805
      Philip Withnall authored
      Instead of rebuilding the entire widget state every time something
      changes, schedule a refresh to happen in an idle callback. This allows
      refreshes to be coalesced, which reduces the number of refreshes
      happening overall. Previously, for example, `gs_app_row_refresh()` was
      being called 3 times as part of constructing and setting up a new
      `GsAppRow` in `GsInstalledPage`.
      This speeds up populating the `GsInstalledPage`.
      `gs_app_row_refresh()` has been removed as a public symbol for
      `GsAppRow` since refreshes should be managed internally to the widget.
      It was unused elsewhere.
      This, in conjunction with the previous commit, decreases the time for
      `gs_installed_page_get_installed_cb()` from 500ms to 300ms (for 114
      apps), and spreads out the cost of setting up the widgets for each app
      row over one or more subsequent main context iterations, which reduces
      freezing of the UI.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
    • Philip Withnall's avatar
      gs-app-row: Add some properties so they can be set at construction time · a289576a
      Philip Withnall authored
      This should speed up the process of setting up a `GsAppRow`, since it
      will (in a following commit) allow the ‘refresh’ calls at construction
      time to be coalesced.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
  12. 12 Jun, 2020 9 commits
    • Matthew Leeds's avatar
      flatpak: Add app to be uninstalled to txn cache · ae8f7e34
      Matthew Leeds authored
      This mirrors what we do for install operations, and ensures that the
      GsApp object used by the GsFlatpakTransaction will be the same one which
      was passed to gs_plugin_app_remove(), which prevents this warning:
      Gs-WARNING **: 21:05:06.803: application
      user/flatpak/chiron1-origin/desktop/org.test.Chiron/master left in
      removing helper
    • Matthew Leeds's avatar
      flatpak: Fix icons for installed bundles · f58c6dbb
      Matthew Leeds authored
      Currently apps installed from .flatpak bundles do not display their
      icons properly (and display gears instead). Fix this by ensuring the
      icon prefix is set in the appstream data so as_icon_load() can find the
    • Matthew Leeds's avatar
      flatpak: Add a test for installing a bundle · c42bad07
      Matthew Leeds authored
      Add a unit test for installing a flatpak bundle, re-using much of the
      code for the flatpakref install test.
    • Matthew Leeds's avatar
      flatpak: Don't use local checkout for flatpak cmd · b682a7fb
      Matthew Leeds authored
      Using a local checkout of flatpak at a hard-coded path for the 'flatpak'
      command is of course bad for portability, but also bad because the
      flatpak plugin might link against a different libflatpak (e.g. the
      installed one).
    • Matthew Leeds's avatar
      flatpak: Don't add NULL origin apps to cache · 85ad4edb
      Matthew Leeds authored
      Currently we add all apps created by gs_flatpak_create_app() to the
      cache (which is just a hash table). However if the origin is not set on
      the app at the time we add it to the cache, its hash table key will have
      a "*" for the origin, like
      "user/flatpak/*/desktop/org.test.Chiron/master". Then if the origin is
      later set to something, say "x", the app will still be returned from the
      cache for a gs_plugin_cache_lookup() call with an ID specifying a
      different origin, say "y". This can cause problems; we should be able to
      assume that using the cache doesn't change the origin being used.
    • Matthew Leeds's avatar
      flatpak: Set app state to INSTALLED more consistently · 0b446de9
      Matthew Leeds authored
      In a couple places we were calling gs_flatpak_create_installed() but not
      setting the app to AS_APP_STATE_INSTALLED. Fix that.
    • Matthew Leeds's avatar
      flatpak: Set a description even without appstream data · a48c18d7
      Matthew Leeds authored
      Otherwise the app may be filtered out by
    • Matthew Leeds's avatar
      flatpak: Set the origin correctly for installed bundles · bd17e476
      Matthew Leeds authored
      If the user opens a .flatpak bundle of an app which is already
      installed, ensure that gs_app_get_origin () returns the correct value
      for the GsApp that gets created, e.g. "hacktml-origin" not "flatpak".
      This fixes an assertion failure in the new unit test for installing
      flatpak bundles.
    • Matthew Leeds's avatar
      flatpak: Fix searching for installed bundles · d306a601
      Matthew Leeds authored
      This commit makes it so that when you search for a flatpak which was
      installed from a bundle, it is returned as a result. The fix is twofold:
      1. Save the XbSilo object which contains the appstream data from
         flatpak_installed_ref_load_appdata() in a hash table and use it in
      2. Set the origin field in the appstream XML to the remote associated
         with the flatpak (whereas currently it's set to "flatpak"). Otherwise
         the app state will not be set by gs_flatpak_refine_app_state_unlocked()
         since the origin doesn't match, and apps with unknown state are hidden
         by gs_plugin_loader_app_is_valid().