1. 27 Nov, 2021 1 commit
  2. 23 Nov, 2021 1 commit
  3. 18 Nov, 2021 1 commit
  4. 15 Nov, 2021 1 commit
    • David Redondo's avatar
      Drop kde4breeze · 3f81ddf3
      David Redondo authored
      It's time. We actually relied on this to export colors, but handle
      this now in startplasma.
  5. 13 Nov, 2021 1 commit
  6. 11 Nov, 2021 1 commit
  7. 09 Nov, 2021 1 commit
  8. 24 Oct, 2021 1 commit
  9. 23 Oct, 2021 1 commit
    • Michail Vourlakos's avatar
      fix paint for standalone buttons with dynamic size · f2b81df6
      Michail Vourlakos authored
      --m_iconSize for standalone buttons can be changed
      dynamically based on user or container preferences.
      Such an example could be the window buttons applet
      that is resizing its buttons based on panel thickness
      or when the applet is on the desktop and the user
      resizes it. Previous implementation was failing
      because even though m_iconSize was set as NULL for
      StandAlone buttons, on the first painting m_iconSize
      was set based on Button::geometry(). This of course
      was failing because the Button::geometry() could change
      afterwards and painting was not considering it to
      calculate m_iconSize again.
  10. 12 Oct, 2021 1 commit
  11. 11 Oct, 2021 3 commits
    • Tatsuyuki Ishi's avatar
      shadow: handle DPR outside the renderer · ee06e262
      Tatsuyuki Ishi authored and Noah Davis's avatar Noah Davis committed
      QPainter's auto-scaling is prone to off-by-one rounding errors and draws on
      fractional coordinates. With this change, we paint on a 1x DPR QPainter and
      scale the shadow offset and strength manually based on DPR.
      This resolves an issue with resulting in seams on the right and bottom
      edges of a menu due to shadow boundaries being off-by-one.
      BUG: 418166
      v2: remove unrelated formatting changes
      - move the DPR helper to ShadowHelper
      - retrieve the DPR from the widget instead of the global QGuiApplication
      - added BUG reference
    • Jonathan Esk-Riddell's avatar
      Update kf5 version requirement to 5.86 · 32621077
      Jonathan Esk-Riddell authored
    • Script Kiddy's avatar
      SVN_SILENT made messages (.desktop file) - always resolve ours · cccbac1a
      Script Kiddy authored
      In case of conflict in i18n, keep the version of the branch "ours"
      To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
  12. 08 Oct, 2021 4 commits
    • Noah Davis's avatar
      Revert "Revert "kstyle: Limit what kinds of QPushButtons can use autoDefault"" · 4195dd40
      Noah Davis authored
      This reverts commit 916cc11f.
      I'm reverting the reversion on master because the reason for reverting
      the original commit seems to have been based purely on an assumption
      about what the patch did rather than testing anything.
    • Jan Blackquill's avatar
      Revert "kstyle: Limit what kinds of QPushButtons can use autoDefault" · 916cc11f
      Jan Blackquill authored
      This reverts commit d4803e4a.
      This commit reintroduces the problem that its precursor was reverted
      for and merged without adequate time for review.
    • Noah Davis's avatar
      kstyle: Add QFocusFrame to non-view/delegate interactive widget · 586e7462
      Noah Davis authored
      There are 2 parts that contain the bulk of the code in this patch.
      Style::event() is used to apply the QFocusFrame to a widget when it gets
      focus with a keyboard input related focus reason. If the focused widget
      has a focusProxy, this makes sure the QFocusFrame is applied to the
      focusProxy instead.
      Style::drawFocusFrame() is mostly what you'd expect. It draws a focus
      frame based on the type of widget the QFocusFrame was applied to. I had
      to do a workaround for QFocusFrame not fully repainting ouside the
      bounds of QSliders and QDials when the handle moves though. What I do is
      check if `_focusFrame` is defined and then `_focusFrame->update()`.
      BUG: 443469
    • Noah Davis's avatar
      kstyle: Limit what kinds of QPushButtons can use autoDefault · d4803e4a
      Noah Davis authored
      This prevents most buttons outside of QDialogButtonBoxes from getting
      the default button visuals/behavior.
      Internally, QPushButton::autoDefault can be explicitly on, explicitly
      off, or automatic (enabled if in a QDialog).
      If autoDefault is explicitly on and not in a dialog, or on/automatic in
      a dialog and has a QDialogButtonBox parent, explicitly enable
      autoDefault, else explicitly disable autoDefault.
      If someone explicitly enabled autoDefault outside of a QDialog, they
      probably had a reason to do that, so we'll avoid interfering with that
      if we can. Unfortunately, there is no way to detect if autoDefault was
      explicitly enabled inside of a QDialog, so that might mess with a small
      minority of applications.
  13. 06 Oct, 2021 1 commit
  14. 05 Oct, 2021 2 commits
  15. 30 Sep, 2021 1 commit
  16. 28 Sep, 2021 1 commit
  17. 26 Sep, 2021 1 commit
  18. 25 Sep, 2021 2 commits
  19. 24 Sep, 2021 5 commits
  20. 23 Sep, 2021 1 commit
  21. 22 Sep, 2021 1 commit
  22. 21 Sep, 2021 2 commits
    • Nate Graham's avatar
      Rename Breeze to Breeze Classic · 84d0d258
      Nate Graham authored
      This is no longer the default color scheme; Breeze Light is. But being
      named "Breeze" implies that is is the default or at least the base,
      rather than simply one of several variants. Let's rename it to "Breeze
      Classic" to make it follow the pattern and avoid subtly giving it more
      textual weight.
    • Nate Graham's avatar
      Delete high contrast color scheme · bb70d9c5
      Nate Graham authored
      This color scheme is a misnomer, and does not actually offer higher
      contrast than other color schemes. In fact its contrast is generally
      worse. As a result it hurts more than it helps. A true "high contrast
      mode" would require changes to the QStyle to make UI elements larger or
      change their borders to actually offer an improvement for people who
      need higher contrast than what is offered by Breeze and Breeze Dark.
      Accordingly, let's delete this color scheme and migrate current users to
      Breeze Dark, which is the shipped theme that looks closest to it, and
      has *better* contrast in many ways.
      BUG: 352506
      BUG: 442286
      FIXED-IN: 5.24
  23. 20 Sep, 2021 1 commit
    • Nate Graham's avatar
      Darken hard-to-read positive, negative, and neutral selection colors · a348854c
      Nate Graham authored
      These colors were previously using the same values as in other contexts,
      but this was not appropriate for the Selection set, because contrast and
      readability were low. This commit addresses that by making the colors
      darker just for the Selection color set. Now they are much more
      This change is made to all four of the Breeze* color schemes, as they
      all suffered from the issue.
      BUG: 406239
      FIXED-IN: 5.23
  24. 19 Sep, 2021 1 commit
  25. 17 Sep, 2021 3 commits
  26. 16 Sep, 2021 1 commit
    • Nate Graham's avatar
      Remove "Draw separator under active window's titlebar" windeco option · 660b7ecc
      Nate Graham authored
      This option is off by default and has been for several years, after it
      was briefly turned on by default and proved to be unpopular with users,
      generating many complaints and bug reports. The line uses a semantically
      inappropriate highlight color which is far too visually bright, and it
      doesn't look good with any of our header-color-using color schemes.
      Arguably it never looked good with older color schemes where the titlebar
      and window background use different colors either. Let's remove this
      BUG: 427422
      FIXED-IN: 5.24