when adding or removing a button for the window decoration in "System Settings -> Application Style -> Window Decorations -> Buttons" and then pressing apply, the new buttons are added or removed from the decoration, but the spacing is not update. I.e. far right button is moved out of the decoration area (adding) or the right button is visible twice with only the left one working correctly (removing). One need to close and reopen the application to get rid of this glitch. See the attached screen shots as an example for adding a button. Reproducible: Always
Created attachment 96170 [details] the normal state of the decoration
Created attachment 96171 [details] the state of the decoration after adding a button
I assume resizing the window will fix it?
yes, resizing fixes it.
ok, so looks like just an update is missing somewhere.
Seems to be only reproducible with breeze? How does the plastik deco behave on your side?
I can confirm, that plastik is unaffected.
I actually think we had this before...
this is not from breeze. (adding ::update all over the place here does not change anything to the issue) most likely kdecoration2
I don't think it's a repaint, but a relayout error, ie. missing ::updateButtonsGeometry() call - you probably need to connect that to DecorationButtonGroup::geometryChanged() for m_*Buttons?
From my recollection (but I can re-double check), updateButtonGeometry *is* called (when would it be otherwise ?). But this is not reflected on the screen. Ok I will double check.
(In reply to Thomas Lübking from comment #10) > I don't think it's a repaint, but a relayout error, ie. missing > ::updateButtonsGeometry() call - you probably need to connect that to > DecorationButtonGroup::geometryChanged() for m_*Buttons? So: checked updateButtonGeometry is not called. adding the connection "helps" but does not fix (not always): not for instance when removing buttons also, I am confused about the suggested change: updateButtonsGeometry does change the DecorationButtonGroup geometry. so at least API wide, this does not look like the most intuitive connection to make ... maybe better Decorationbutton created/destroyed/geometry changed ? (that would make more sense, I guess ...)
Just looked up the buttongroup code for emitted signals (and geometryChanged was the only called) Connecting the canged signal of the deco settings should do as well.
ps: connecting it delayed!
Tried to connect (delayed) decorationButtonsLeftChanged and decorationButtonsRightChanged from DecorationSettings. Works when adding buttons not when removing. Also, (OT) in the meanwhile, I've noticed that KDecoration2::DecoratedClient::widthChanged is called at every window move event. (without resize). Should I file a separate bug report ?
I guess I should write a virtuality deco ;-) > Works when adding buttons not when removing. That's rather odd, but there's probably even better: void DecorationSettings::decorationButtonsLeftChanged(const QVector<KDecoration2::DecorationButtonType>&); and void DecorationSettings::decorationButtonsRightChanged(const QVector<KDecoration2::DecorationButtonType>&); > Should I file a separate bug report ? Sure, though it looks like the only emitter is Window::setGeometry(const QRect &rect) and there is if (rect.width() != oldRect.width()) { emit window()->widthChanged(rect.width()); } So either the old or the new geometry would alway be junk....
(In reply to Thomas Lübking from comment #16) > I guess I should write a virtuality deco ;-) > > > Works when adding buttons not when removing. > That's rather odd, but there's probably even better: > > void DecorationSettings::decorationButtonsLeftChanged(const > QVector<KDecoration2::DecorationButtonType>&); > and > void DecorationSettings::decorationButtonsRightChanged(const > QVector<KDecoration2::DecorationButtonType>&); > hmm that's the one I used > > Should I file a separate bug report ? > Sure, though it looks like the only emitter is > Window::setGeometry(const QRect &rect) and there is > if (rect.width() != oldRect.width()) { > emit window()->widthChanged(rect.width()); > } > > So either the old or the new geometry would alway be junk....
"changed" is indeed a functor pointing one of them, so that's correct. Though what's odd is that those changed events should wipe and recreate the button groups, so either the group is not updated when removing a button or you should get the signal... -> Don't you get the signal or does ::updateButtonGeometry fail?
(In reply to Thomas Lübking from comment #18) > "changed" is indeed a functor pointing one of them, so that's correct. > > Though what's odd is that those changed events should wipe and recreate the > button groups, so either the group is not updated when removing a button or > you should get the signal... > > -> Don't you get the signal or does ::updateButtonGeometry fail? Getting somewhere :) So: signal is sent (and recieved), updateButtonGeometry succeeds. But what's missing in case of button removal, is a repaint (::update()) Combination of both seems to be working in all cases.
Git commit ed08414b124e85b895ad3f553d590377c27af131 by Hugo Pereira Da Costa. Committed on 27/12/2015 at 16:26. Pushed by hpereiradacosta into branch 'master'. Call updateButtonGeometry after decorationButtonsLeftChanged and decorationButtonsRightChanged added ::update at the end of updateButtonGeometry M +12 -0 kdecoration/breezedecoration.cpp M +1 -0 kdecoration/breezedecoration.h http://commits.kde.org/breeze/ed08414b124e85b895ad3f553d590377c27af131
Git commit 768ae398483060740137331d4483aa4ecd4e005e by Hugo Pereira Da Costa. Committed on 27/12/2015 at 16:28. Pushed by hpereiradacosta into branch 'Plasma/5.5'. Call updateButtonGeometry after decorationButtonsLeftChanged and decorationButtonsRightChanged added ::update at the end of updateButtonGeometry M +12 -0 kdecoration/breezedecoration.cpp M +1 -0 kdecoration/breezedecoration.h http://commits.kde.org/breeze/768ae398483060740137331d4483aa4ecd4e005e
PS: thanks for the help. Will also fix oxygen.
Git commit 6afe7689a030c00351fb80cffacbf8c63691fee8 by Hugo Pereira Da Costa. Committed on 27/12/2015 at 16:35. Pushed by hpereiradacosta into branch 'Plasma/5.5'. Call updateButtonGeometry after decorationButtonsLeftChanged and decorationButtonsRightChanged added ::update at the end of updateButtonGeometry M +11 -0 kdecoration/oxygendecoration.cpp M +1 -0 kdecoration/oxygendecoration.h http://commits.kde.org/oxygen/6afe7689a030c00351fb80cffacbf8c63691fee8
Git commit 4280d9b484af5315d9522c682d73462b4b98de7a by Hugo Pereira Da Costa. Committed on 27/12/2015 at 16:34. Pushed by hpereiradacosta into branch 'master'. Call updateButtonGeometry after decorationButtonsLeftChanged and decorationButtonsRightChanged added ::update at the end of updateButtonGeometry M +11 -0 kdecoration/oxygendecoration.cpp M +1 -0 kdecoration/oxygendecoration.h http://commits.kde.org/oxygen/4280d9b484af5315d9522c682d73462b4b98de7a
(In reply to Hugo Pereira Da Costa from comment #15) > Also, (OT) in the meanwhile, I've noticed that > KDecoration2::DecoratedClient::widthChanged is called at every window move > event. (without resize). > Should I file a separate bug report ? Don't know if this is still an issue, but i aligns with my observation, that moving the window fixes the original bug. BTW: Thx 4 fixing.