1. 18 May, 2021 1 commit
    • Fabian Vogt's avatar
      Fix informing the underlying widget when leaving SplitterProxy · ae9639f7
      Fabian Vogt authored
      While the SplitterProxy is active, it intercepts all relevant events, so that
      the underlying widget still thinks it's in the same "on splitter" state. When
      the SplitterProxy is left, the underlying widget is sent a HoverLeave/HoverMove
      event to make it aware of the new current cursor position. Without this, it
      doesn't know that it's not supposed to be in the "on splitter" state, and when
      it regains focus it just re-activates the SplitterProxy at the current cursor
      This was broken by accident in d201a1f1 ("Fix SplitterProxy not clearing
      when above another QSplitterHandle"), which moved the hide() call past the
      call to QCoreApplication::sendEvent. Previously that made isVisible() false,
      which also prevented the interception of the HoverLeave/HoverMove events.
      BUG: 436473
      (cherry picked from commit f99b7ef6)
  2. 04 May, 2021 1 commit
  3. 09 Apr, 2021 2 commits
    • Fabian Vogt's avatar
      Fix SplitterProxy not clearing when above another QSplitterHandle · cc613558
      Fabian Vogt authored
      When two SplitterHandles are next to each other, like at the intersection of a
      horizontal and vertical splitter (|-), then it's possible that hiding the proxy
      of one of those handles causes the other handle to gain focus immediately,
      which activates the SplitterProxy again. Before this patch, it would then
      continue clearing after reenabling itself, leading to an inconsistent state.
      BUG: 431921
      (cherry picked from commit d201a1f1)
    • Fabian Vogt's avatar
      Fix logic error in SplitterProxy::setEnabled · 10fbc0ea
      Fabian Vogt authored
      It clears the splitter when enabling it, that seems wrong.
      Despite this bug, it still mostly worked before because the eventFilter checked
      for _enabled anyway.
      (cherry picked from commit 4b10546c)
  4. 30 Mar, 2021 1 commit
  5. 29 Sep, 2020 1 commit
  6. 06 Sep, 2020 1 commit
  7. 01 Sep, 2020 1 commit
  8. 30 Jun, 2020 1 commit
  9. 18 Jun, 2020 1 commit
  10. 17 Jun, 2020 1 commit
  11. 05 May, 2020 1 commit
  12. 31 Mar, 2020 1 commit
  13. 24 Mar, 2020 1 commit
  14. 17 Mar, 2020 1 commit
    • Paul McAuley's avatar
      Fix Defaults not being set properly in Breeze window decoration settings for... · f944832f
      Paul McAuley authored and Nate Graham's avatar Nate Graham committed
      Fix Defaults not being set properly in Breeze window decoration settings for 'Draw a circle around close button'
      Summary: This fixes a small bug in the Breeze window decoration settings where clicking on 'Defaults' did nothing to change 'Draw a circle around close button' . This patch now causes 'Draw a circle around close button' to default correctly.
      Reviewers: #breeze, hpereiradacosta
      Reviewed By: hpereiradacosta
      Subscribers: ngraham, plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D28087
  15. 10 Mar, 2020 1 commit
  16. 25 Feb, 2020 1 commit
  17. 18 Feb, 2020 2 commits
  18. 10 Feb, 2020 1 commit
  19. 06 Feb, 2020 1 commit
  20. 31 Jan, 2020 1 commit
    • Filip Fila's avatar
      [wallpapers] Use more high-quality JPEGs for Next · df58788d
      Filip Fila authored
      Due to filesize concerns, we optimized the Volna wallpaper to be JPEG compressed at 90% quality.
      JPEGs seems like the right way to go, but at 90% there is a noticeable loss of sharpness and JPEG artifacts appear, both of which are more prominent the smaller the resolution.
      I used the same tool (squoosh) to generate more high quality JPEGs, paying attention to how each resolution responded to a certain quality setting.
      In the end I had to use values between 94 and 98 in order to ensure there is no noticeable difference with the original PNGs.
      This brings up the total file size to 17.4 MiB, which I think is still fine, especially given that this is our default wallpaper for an LTS release.
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D27045
  21. 29 Jan, 2020 1 commit
  22. 28 Jan, 2020 2 commits
    • Nate Graham's avatar
      Work around an issue with changing the wallpaper's filetype · 8f4ea0a9
      Nate Graham authored
      Because of the issue described in T12611, changing the filetype of the Next wallpaper is
      problematic and will cause a black screen on upgrade.
      This terrible horrible patch works around the issue by using the .png filename extension
      even though this is not accurate. That way, the file names are the same as the old
      versions of the Next wallpaper and will be loaded correctly. Using the wrong filename
      extension does not actually cause any problems, it's just inaccurate. a `README` file is
      placed next to the images to explain this.
      I'm sorry.
      Long-term, we should investigate T12611.
      Test Plan:
      Have previous Next wallpaper (Ice Cold) installed
      Replace it on disk with Volna in original JPEG form
      restart plasmashell -> black screen
      Try the above again with this patch
      restart plasmashell -> new wallpaper visible
      Reviewers: davidedmundson, #plasma, ognarb
      Reviewed By: ognarb
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D26972
    • Nate Graham's avatar
      Replace Ice Cold with Volna for Plasma 5.18 · e920200e
      Nate Graham authored
      Summary: Volna won the wallpaper competition, so time to add it to Breeze as the new default!
      Test Plan: Apply patch, compile, and restart plasmashell
      Reviewers: #vdg, #plasma, davidedmundson
      Reviewed By: #plasma, davidedmundson
      Subscribers: raveomelette, IlyaBizyaev, Luwx, ndavis, broulik, rikmills, plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D26953
  23. 22 Jan, 2020 1 commit
  24. 21 Jan, 2020 1 commit
  25. 16 Jan, 2020 1 commit
  26. 15 Jan, 2020 5 commits
  27. 14 Jan, 2020 1 commit
  28. 13 Jan, 2020 3 commits
    • Noah Davis's avatar
      Make checkboxes/radiobuttons use Window Background in windows and View Backround in lists · 3e9cd8d1
      Noah Davis authored
      Summary: If the widget has an item view parent, use the View Background color. Otherwise, use Window Background.
      Test Plan: {F7881597, size=full}
      Reviewers: #vdg, #breeze, hpereiradacosta, ngraham
      Reviewed By: #vdg, hpereiradacosta
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D26639
    • Noah Davis's avatar
    • Noah Davis's avatar
      Always render checkbox/radiobutton background · 98781f18
      Noah Davis authored
      QQC2/Kirigami checkboxes and radio buttons can turn invisible when rendered over a selected item because their background isn't rendered and they don't have any hacks to detect when they're being rendered over a selected list item.
      While the problem isn't technically a Breeze QStyle problem and a hack could be made for QQC2/Kirigami, I don't think there's any great style benefit to not rendering a background for the checkbox. I suppose there is a performance benefit to not rendering a checkbox background except for when the background is different from normal. In my testing with GammaRay's paint analyzer, the checkbox background has a cost less than 5%. The radiobutton background has a cost of 15-20% (maybe it can be improved?).
      Reviewers: #vdg, #breeze, #plasma, hpereiradacosta, ngraham
      Reviewed By: #vdg, hpereiradacosta, ngraham
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D26572
  29. 06 Jan, 2020 1 commit
  30. 05 Jan, 2020 1 commit
  31. 04 Jan, 2020 1 commit