1. 12 Oct, 2020 1 commit
    • Andreas Haratzis's avatar
      Fix for occasional background glitches behind transparent Menus, especially... · 855d4497
      Andreas Haratzis authored and Nate Graham's avatar Nate Graham committed
      Fix for occasional background glitches behind transparent Menus, especially when hovering over menu elements.
      
      Bug: 399680
      
      Issue:
      Breeze sets the WA_TranslucentBackground attribute on Menu widgets to achieve transparency.
      This implies WA_NoSystemBackground, which makes Qt not repaint the background when content changes.
      This is fine for things like tooltips which don't change content, but for dynamic content (like hovering over menus), Breeze ends up painting over the previous frame.
      
      Fix:
      We render menu panels with CompositionMode_Source to ensure the previous frame is obliterated.
      We could reset the buffer by painting transparent pixels first, but that is wasteful.
      
      Notes:
      I have ensured that overlapping transparent menus still appear OK (they are rendered over each other with the compositor).
      On Wayland, occasionally colours appear behind the rounded borders. I believe this is a kwin issue because it doesn't occur in X11.
      
      
      (cherry picked from commit 01f0c885)
      855d4497
  2. 09 Oct, 2020 1 commit
  3. 08 Oct, 2020 2 commits
  4. 06 Oct, 2020 1 commit
  5. 05 Oct, 2020 1 commit
  6. 02 Oct, 2020 1 commit
  7. 29 Sep, 2020 1 commit
  8. 28 Sep, 2020 1 commit
  9. 27 Sep, 2020 1 commit
  10. 24 Sep, 2020 1 commit
  11. 22 Sep, 2020 1 commit
  12. 21 Sep, 2020 2 commits
  13. 20 Sep, 2020 1 commit
  14. 19 Sep, 2020 1 commit
  15. 18 Sep, 2020 1 commit
    • Vlad Zahorodnii's avatar
      [kstyle] Ensure that shadows are destroyed after decorated windows · e4fa083c
      Vlad Zahorodnii authored
      The order in which the underlying window and the shadow are destroyed is
      undefined. In most cases, the shadow is destroyed after the window, but
      in rare cases it may be vice versa, for example it's the case with popup
      menus in Dolphin. If the shadow is destroyed before the window, then
      the window will be shadowless when the compositor animates it.
      
      The only way to guarantee that the shadow is destroyed after the window
      is to create a parent-child relationship between two.
      
      Given that the widget and the window have different lifetimes, we have
      to be extra careful with keeping dangling pointers out of _shadows.
      
      
      (cherry picked from commit 5f62d1c7)
      e4fa083c
  16. 17 Sep, 2020 5 commits
  17. 16 Sep, 2020 3 commits
  18. 15 Sep, 2020 1 commit
  19. 14 Sep, 2020 1 commit
  20. 11 Sep, 2020 1 commit
  21. 10 Sep, 2020 1 commit
  22. 06 Sep, 2020 1 commit
  23. 01 Sep, 2020 2 commits
  24. 31 Aug, 2020 1 commit
  25. 28 Aug, 2020 2 commits
    • Nate Graham's avatar
      [kstyle] Reverse default sort order indicator arrow direction · 50eea309
      Nate Graham authored
      The direction of the sort order indicator arrows has historically been
      controversial:
      
      1. Camp A asserts that the arrow should reflect the currently applicable
         word: "ascending" or "descending". For example Ascending order should
         be represented by the arrow pointing up. It's ascending, get it?
      
      2. Camp B asserts than the arrow should reflect the visible order of
         items in the view. For example when the biggest things are on top,
         the arrow should be pointing down; it's showing you the direction of
         the visible items: big to small.
      
      3. Camp A then correctly points out that if Camp B gets their way, the
         arrow no longer matches the word displayed in the UI ("ascending"
         or "descending).
      
      However over the years we have accidentally solved this dilemma! We all
      pretty much agree that the terms "ascending" and "descending" are
      confusing to users, and we have replaced them with human-readable
      descriptions such as "A-Z" and "Largest first". As a result, the arrows
      are no longer consistent with the words "ascending" or "descending"
      because we no longer show those words in the UI anymore. So the only
      remaining thing for the arrow to be consistent with is the set of items
      displayed immediately below it. For this purpose, reversing the default
      order per Camp B is more appropriate because then the arrow points in
      the direction of the sorting: biggest on top gets a downward-pointing
      arrow, and smallest on top gets an upward-pointing arrow.
      
      There is a hidden option in Breeze that does just that; this patch flips
      it from false to true to effect the above change.
      50eea309
    • Nate Graham's avatar
  26. 23 Aug, 2020 1 commit
  27. 11 Aug, 2020 2 commits
  28. 10 Aug, 2020 1 commit
  29. 06 Aug, 2020 1 commit