Bug 315400

Summary: Dialog windows draw extra internal margins
Product: [Plasma] Breeze Reporter: rockonthemoonfm
Component: QStyleAssignee: kdelibs bugs <kdelibs-bugs>
Status: CONFIRMED ---    
Severity: minor CC: cfeck, kdelibs-bugs, nate, popov895
Priority: NOR Keywords: usability
Version: 5.19.5   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In: 5.17.0
Bug Depends on:    
Bug Blocks: 303462    

Description rockonthemoonfm 2013-02-18 17:33:34 UTC
you can see that Open/Save dialog has double margins around the window.


Reproducible: Always



Expected Results:  
normal margin, correct ui.
Comment 1 Christoph Feck 2013-02-20 23:33:03 UTC
There are no double margins, but the margin should only be applied to the lower part of the window, not the complete window.
Comment 2 rockonthemoonfm 2013-07-04 16:43:15 UTC
bug still valid for 4.11 beta 2
Comment 3 Nate Graham 2017-11-28 21:39:51 UTC
Still present in Plasma 5.11.3. It's not so much that file chooser dialog windows have double borders, but rather that they their UI elements are inset a bit. So even if you set the use the No Borders setting, the dialogs still *effectively and visually* show a border.
Comment 4 Nate Graham 2019-06-28 21:39:56 UTC
Fixed with changes in Breeze: https://cgit.kde.org/breeze.git/commit/?id=e15989fb1f0d73200e5a328b86170af85457a114
Comment 5 Nate Graham 2020-09-29 17:58:08 UTC
I closed this incorrectly, sorry. The issue--if any--is that dialog windows have larger internal padding compared to non-dialog windows. As a result, when window-decoration-drawn window borders are turned on, dialog windows have implausibly enormous borders, and when windeco borders are turned off, it looks like they are still on.

Probably what we need to do is to make dialog windows have no extra internal margins, and instead add margins only ad needed to the actual content items within the dialogs.
Comment 6 Nate Graham 2020-09-29 18:01:17 UTC
*** Bug 427032 has been marked as a duplicate of this bug. ***
Comment 7 Nate Graham 2020-09-29 20:27:49 UTC
Actually now I'm not sure whether these extra margins come from Breeze, or some frameworks component that generates the dialog.

Christoph, any chance you know off the top of your head?
Comment 8 Christoph Feck 2020-09-30 00:37:23 UTC
I am not sure if I understand the issue, but could you check if breeze returns different values for PM_Layout*Margin and (deprecated) PM_DefaultTopLevelMargin?
Comment 9 popov895 2020-09-30 08:33:58 UTC
Can you try

> m_processList.setContentsMargins(0,0,0,0);
See https://invent.kde.org/himanshur/ksysguard/-/blob/master/gui/SensorDisplayLib/ProcessController.cpp#L148
Comment 10 popov895 2020-09-30 18:19:26 UTC
(In reply to popov895 from comment #9)
> Can you try
> 
> > m_processList.setContentsMargins(0,0,0,0);
> See
> https://invent.kde.org/himanshur/ksysguard/-/blob/master/gui/
> SensorDisplayLib/ProcessController.cpp#L148
Ohh, of course it doesn't make the margins smaller. Shame on me:(
Comment 11 Nate Graham 2020-10-04 15:29:00 UTC
Breeze does:

} else if (auto dialog = qobject_cast<const QDialog*>(widget)) {
    auto margins = dialog->contentsMargins();
    const_cast<QDialog*>(dialog)->setContentsMargins(margins.left(), qMax(margins.top(), 1), margins.right(), margins.bottom());
    painter->setPen(QPen(_helper->separatorColor(_toolsAreaManager->palette()), PenWidth::Frame * widget->devicePixelRatio()));
    painter->drawLine(widget->rect().topLeft(), widget->rect().topRight());
}


...But this doesn't seem to be responsible.