IJHack / QtPass / 35599801048

93%

push

github

Menu bar follows a KDE theme switch like the toolbar does (#1874)

* Menu bar follows a KDE theme switch like the toolbar does

Breeze's ToolsAreaManager stamps one "header" palette on the QMainWindow's
menu bar and its top toolbars, and after a runtime light/dark switch it
re-applies that palette from a KSharedConfig it never reparses, so both
bars keep the previous theme. #1669 filtered PaletteChange on the toolbar
and dropped the stale palette; the menu bar, new in 2.0, was left out and
stayed dark on a light window (#1868).

The filter now watches the menu bar too, and one deferred slot judges both
bars. Three things the toolbar fix got wrong are put right for both on the
way, each found by trying to break the generalisation:

- The bars' background role is Button, so the "visible reset" painted the
  button colour (#fcfcfc on Breeze Light, #31363b on Dark), not the window
  colour, and once autoFillBackground was on a header Breeze later stamped
  rightly (dark→light round trip) was kept in the palette yet painted as
  Button. The reset bars paint the Window role, which is also what a header
  palette puts there.
- A bar's palette() reads the inactive colour group while another window
  (the settings app, during a switch) has focus, and Breeze's header set
  has inactive colours of its own; the comparison reads the Active group on
  both sides.
- Breeze stamps the header at startup through the same code, from a fresh
  config; a scheme with a dark header on a light body was undone by QtPass
  alone. A stamp is only suspect once an ApplicationPaletteChange has
  reached the window in its lifetime, noted in MainWindow::event().

Tests (tst_mainwindow, data-driven over both bars): the stale stamp is
dropped after a switch, with the switch drained first so that the bar's own
PaletteChange has to trigger it (the menuBar row is red without the menu
bar filter: the toolbar's PaletteChange from the switch itself used to run
the slot for it), the reset ba... (continued)

21 of 21 new or added lines in 1 file covered. (100.0%)

7294 of 9230 relevant lines covered (79.02%)

79.16 hits per line