1. 17 Sep, 2020 1 commit
  2. 16 Sep, 2020 1 commit
  3. 15 Sep, 2020 1 commit
  4. 09 Sep, 2020 1 commit
  5. 25 Aug, 2020 2 commits
  6. 17 Aug, 2020 1 commit
  7. 17 Jun, 2020 3 commits
  8. 16 Jun, 2020 2 commits
  9. 10 Jun, 2020 1 commit
  10. 09 Jun, 2020 4 commits
  11. 06 Jun, 2020 1 commit
  12. 04 Jun, 2020 4 commits
  13. 14 May, 2020 1 commit
  14. 07 Apr, 2020 2 commits
  15. 01 Apr, 2020 1 commit
  16. 30 Mar, 2020 2 commits
  17. 27 Mar, 2020 1 commit
    • chriadam's avatar
      [nemo-qml-plugin-calendar] Prevent flicker of attendees. Contributes to JB#32993 · 1ba0729c
      chriadam authored
      The CalendarWorker observes storageModified() signals sent from mkcal.
      In mkcal side, when storageModified() is emitted, loaded ranges are
      invalidated and must be re-loaded.  Thus, when CalendarWorker observes
      the storageModified() signal, it tells the CalendarManager that it
      needs to rebuild its required ranges (from connected AgendaModel
      and currently active EventQuery instances).  The CalendarManager
      then asks the CalendarWorker to load instances within that range
      into the calendar from storage.
      If an EventQuery is refreshed as part of this process, it previously
      always emitted attendeesChanged() even if the data in the backend
      remained the same.  This commit ensures that we load the data from
      the backend, and compare it to the currently cached data, and only
      emit attendeesChanged() if they are indeed different.
      Finally, it guards against a race condition case where if multiple
      storageModified() signals are received in sequence, the some attempts
      to load the attendees may fail due to the storage having invalidated
      its loaded ranges.  In this case, the results we receive back will
      be invalid, and should be ignored (and in this case, the data for
      the event will be reloaded again, as triggered by storageModified()).
  18. 11 Mar, 2020 3 commits
  19. 10 Mar, 2020 1 commit
  20. 05 Mar, 2020 1 commit
  21. 25 Feb, 2020 2 commits
  22. 11 Feb, 2020 1 commit
  23. 10 Feb, 2020 1 commit
  24. 13 Jan, 2020 2 commits
    • flypig's avatar
      Merge branch 'jb46554' into 'master' · 8b6b4c1c
      flypig authored
      Use ResponseType if available to show calendar attendance
      See merge request !47
    • flypig's avatar
      [nemo-qml-plugin-calendar] Use ResponseType if available to show calendar... · d44e8e9e
      flypig authored
      [nemo-qml-plugin-calendar] Use ResponseType if available to show calendar attendance. Contributes to JB#46554
      The ResponseType returned by an EAS server indicates how the user
      responded to a event invitation request (Accepted, Declined, Tentative).
      The ownerStatus is set to this value if available, which is used by the
      UI to display the user's attendance status.
      The previous behaviour used the list of invited users and attendance
      status assigned to each to determine the user's response. The EAS server
      won't always provide these values. Moreover, if the user has multiple
      email addresses for an account the address used for the invitation may
      not match the account username, preventing the value from being picked
      up. In case the value is available and set, it's still used in
      preference to the ResponseType.