Bug 315400

Summary:	Dialog windows draw extra internal margins
Product:	[Plasma] Breeze	Reporter:	rockonthemoonfm
Component:	QStyle	Assignee:	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:	https://cgit.kde.org/breeze.git/commit/?id=e15989fb1f0d73200e5a328b86170af85457a114	Version Fixed In:	5.17.0
Sentry Crash Report:
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.