1. 16 Nov, 2019 1 commit
  2. 24 Mar, 2019 1 commit
  3. 01 Nov, 2018 1 commit
    • David Faure's avatar
      Eventviews: properly fall back to color-generator if ColorAttribute is absent · 4dab2d3b
      David Faure authored
      This was introduced by 1ec2e08a which only called the color-generator
      code when there *is* a ColorAttribute on the collection (with an
      invalid color, which seems unlikely), rather than when the attribute
      isn't there.
      I thought this was the bug that made all new resources red (with caldav)
      but actually that seems to come from the resource itself. So now I'm not
      100% sure about this commit anymore, although it still seems to make
      sense to me -- for other resources, possibly.
      Test Plan:
      Disabling the code that reads from the ColorAttribute
      and removing all "Resources Colors" entries from ~/.config/eventviewsrc,
      the colors are properly generated.
      Reviewers: ochurlaud, dkurz, dvratil
      Reviewed By: ochurlaud, dkurz
      Subscribers: #kde_pim
      Differential Revision: https://phabricator.kde.org/D16508
  4. 23 May, 2018 1 commit
  5. 31 Oct, 2017 1 commit
  6. 26 Aug, 2017 1 commit
    • Olivier Churlaud's avatar
      Event view can use the CollectionColorAttribute color · 1ec2e08a
      Olivier Churlaud authored
      This introduces 3 changes in Helper:
       - 3 Helper functions are now exported
       - resourceColor() checks if a color is set in the preferences files. If yes, it uses it. If not, it checks if there is a CollectionColorAttribute in the collection. If yes, it uses it else it call the resourceColor() from prefs (that can create a new color or return an invalid one)
       - setResourceColor() set a color in the preferences files ONLY IF it's not the same as the CollectionColor Attribute.
      Bug: 328862
      Differential Revision: https://phabricator.kde.org/D7500
  7. 09 Dec, 2015 2 commits