1. 10 Dec, 2020 1 commit
  2. 09 Dec, 2020 1 commit
  3. 08 Dec, 2020 3 commits
  4. 06 Dec, 2020 2 commits
  5. 05 Dec, 2020 1 commit
    • Philip Withnall's avatar
      tests: Allow progress to be unknown or 100% after flatpak installation · 243af75a
      Philip Withnall authored
      This might fix a flaky test in the CI, where sometimes the progress
      after installation is queried as 100%, and sometimes it’s queried as
      I think the race happens because flatpak operations (and progress
      updates) happen in another thread, and the unit test code can query at
      the point of installation being complete (seeing 100%), or once the app
      progress has been reset after installation (seeing unknown).
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <pwithnall@endlessos.org>
      Fixes: #1107
  6. 04 Dec, 2020 10 commits
  7. 03 Dec, 2020 9 commits
  8. 02 Dec, 2020 4 commits
  9. 01 Dec, 2020 2 commits
    • Milan Crha's avatar
      gs-application: Search for the installed application in app.launch · ad0e68b4
      Milan Crha authored
      Clicking 'Launch' button in the "application was installed" bubble doesn't
      launch just installed flatpak application. The problem is that the app.launch
      is called only with the application ID, and then a GsApp instance is just
      created from this ID, which is not enough to even refine the internal things,
      because the app doesn't know what plugin it belongs to.
      The fix is to:
       * pass both management plugin and the application ID to app.launch
       * search for the application by its ID
       * traverse returned list of found applications and find a matched installed application from the given plugin
       * launch the found application
      Closes #1103
      Closes !555
    • Kjartan Maraas's avatar
      Update Norwegian Bokmål translation · 6b275139
      Kjartan Maraas authored and Administrator's avatar Administrator committed
      (cherry picked from commit b06d8444)
  10. 30 Nov, 2020 6 commits
    • Phaedrus Leeds's avatar
      gs-app: Add missing pointer validation · 62989852
      Phaedrus Leeds authored
      Add missing g_return_*_if_fail() calls, and, in a few cases, don't use
      the app pointer or the priv pointer before validation. It's safe to call
      get_instance_private() on a pointer before validating it, since that
      only does pointer arithmetic.
    • Phaedrus Leeds's avatar
      Add a message in the UI when an app is renamed · 282e3efb
      Phaedrus Leeds authored
      Without a message the user may be confused why they can't find the app
      by looking for the name they remember.
    • Aurimas Černius's avatar
      Updated Lithuanian translation · 56031d60
      Aurimas Černius authored
    • Phaedrus Leeds's avatar
      flatpak: Fix displaying renamed apps · 3a14718a
      Phaedrus Leeds authored
      Currently for apps that have been renamed on Flathub, at least
      org.gnome.iagno for example, the appstream data only exists under the
      new name, so the app doesn't get properly displayed in the updates list
      as it should so it can be updated to the new name. Instead there are
      errors in the log "GsPluginFlatpak no match for ....: no results for
      XPath query" and later "Gs app invalid as no name ..."
      So use the appstream data under the new name in such circumstances. This
      is not perfect in that we'll show the new name before the app has
      actually been renamed, but it's certainly better than not showing the
      app at all, and in practice renames are often just to change the app ID.
      This makes renamed apps display properly in the Installed and Updates
      lists, but there is still a remaining issue: after updating an app to
      a new name, it doesn't show in the Installed list until after
      gnome-software is closed and restarted.
    • Phaedrus Leeds's avatar
      flatpak: Follow end-of-life-rebase redirects · c4c80869
      Phaedrus Leeds authored
      When an app is renamed, appropriate metadata is set server-side so that
      FlatpakTransaction::end-of-lifed-with-rebase is emitted. On the CLI the
      user can choose whether to install the renamed app. GNOME Software
      currently ignores the signal so such apps stay on their old names
      forever. This commit makes g-s follow such redirects and install the new
      app without user interaction, since that is what most users will want. A
      follow-up commit will add a message in the UI so the user can be
      informed in case the application's name is changing (as opposed to only
      the application ID changing, which shouldn't be user-visible).
      Note that in the special case where the installed commit is the one with
      the eol-rebase metadata (as opposed to being an older commit), such apps
      will not be returned by
      flatpak_installation_list_installed_refs_for_update() without this
      patch: https://github.com/flatpak/flatpak/pull/3945
    • Marek Černocký's avatar
      Fixed Czech translation · ab78e3a8
      Marek Černocký authored
  11. 29 Nov, 2020 1 commit