Bug 105259 - Area style dialog badly aligned
Summary: Area style dialog badly aligned
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.4.0.0.alpha0+
Hardware: All All
: highest major
Assignee: Not Assigned
URL:
Whiteboard: target:5.4.0 target:5.3.0.2
Keywords:
Depends on:
Blocks: Area-Fill-Tab
  Show dependency treegraph
 
Reported: 2017-01-11 16:45 UTC by Heiko Tietze
Modified: 2017-01-14 13:56 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot on Windows (88.61 KB, image/png)
2017-01-11 16:45 UTC, Heiko Tietze
Details
Screenshot with gtk3 (424.47 KB, image/png)
2017-01-12 13:39 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Heiko Tietze 2017-01-11 16:45:10 UTC
Created attachment 130320 [details]
Screenshot on Windows

This is a follow-up to bug 103225 where the issue was tried to get solved by a fix dialog size. But the problem exists since the controls are not well aligned and needs to be fixed soon. It is a show stopper for 5.3 as the controls are almost not accessible.

Version: 5.4.0.0.alpha0+
Build ID: db4badfc971b9cc60809c3408f579bae04a77c34
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-10_23:25:07
Locale: de-DE (de_DE); Calc: group
Comment 1 Telesto 2017-01-11 17:04:29 UTC
Confirming with:
Version: 5.4.0.0.alpha0+
Build ID: db4badfc971b9cc60809c3408f579bae04a77c34
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-10_23:25:07
Locale: nl-NL (nl_NL); Calc: CL
Comment 2 Buovjaga 2017-01-12 10:32:58 UTC
The revert in 103225 needs to be reverted. It should never have been pushed to 5.3 in the first place.

There is NO WAY we can fix AND test this in ONE WEEK.

PLEASE REVERT IMMEDIATELY.
Comment 3 Heiko Tietze 2017-01-12 13:39:29 UTC
Created attachment 130358 [details]
Screenshot with gtk3

Version: 5.4.0.0.alpha0+
Build ID: 229d98e94a5d6b350c4d5fd5469be8e4a260a40c
CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group

(The patch with a fix size was not a solution.)
Comment 4 Buovjaga 2017-01-12 14:14:56 UTC
(In reply to Heiko Tietze from comment #3)
> Created attachment 130358 [details]
> Screenshot with gtk3
> 
> Version: 5.4.0.0.alpha0+
> Build ID: 229d98e94a5d6b350c4d5fd5469be8e4a260a40c
> CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; VCL: gtk3; 
> Locale: en-US (en_US.UTF-8); Calc: group
> 
> (The patch with a fix size was not a solution.)

Maybe, but:
1. Now it is broken on every platform and not just Linux
2. Now it is broken much more noticeably and consistently

Regarding point 2, I am still running a build from before the revert on Linux. With gtk3 backend, I am not seeing ANY clipping problems (like in your screenshot). I'm sure this is theme-dependent, but tells you just how it is NOT consistently broken.
Comment 5 Maxim Monastirsky 2017-01-12 15:27:31 UTC
FYI we can do things differently with gtk3, i.e.

if (Application::GetToolkitName() == "gtk3")
{
    // do something
}

Surely this isn't the "right" solution, but it might be good enough until we find a better one.
Comment 6 Heiko Tietze 2017-01-12 15:38:19 UTC
(In reply to Maxim Monastirsky from comment #5)
> FYI we can do things differently with gtk3, i.e.
> 
> if (Application::GetToolkitName() == "gtk3")
> {
>     // do something
> }
> 
> Surely this isn't the "right" solution, but it might be good enough until we
> find a better one.

The current situation without the patch of bug 103225 is that everyone will get misaligned controls. Undoing the patch, which was decided to do in the ESC today, leads to huge whitespace, not that much of a problem on gtk3. IIRC, gtk3 was just the DE (rather theme) that is most affected by the bug here. But in the end it needs to double checked again as I'm running Qt.
Comment 7 Maxim Monastirsky 2017-01-12 16:07:04 UTC
(In reply to Heiko Tietze from comment #6)
> The current situation without the patch of bug 103225 is that everyone will
> get misaligned controls. Undoing the patch, which was decided to do in the
> ESC today, leads to huge whitespace, not that much of a problem on gtk3.
Right. What I was suggesting is to re-apply the patch of bug 103225, but adjust it in a way that will not introduce the huge whitespace. i.e. use fixed size everywhere, but use 750x550 only under gtk3, else use smaller fixed size.
Comment 8 Tomaz Vajngerl 2017-01-12 16:53:43 UTC
Sorry, I commited http://cgit.freedesktop.org/libreoffice/core/commit/?id=00db9f51215d11da3b27685a39ec940ecd65e387 with the bug number tdf#103225

The dialog should adapt to content now, however I need to check this on Windows..
Comment 9 Buovjaga 2017-01-12 18:14:26 UTC
(In reply to Tomaz Vajngerl from comment #8)
> Sorry, I commited
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=00db9f51215d11da3b27685a39ec940ecd65e387 with the bug number tdf#103225
> 
> The dialog should adapt to content now, however I need to check this on
> Windows..

It seems otherwise OK with gtk3, but the Gradient tab Center (X / Y) Angle -labels still go behind the widgets like in Heiko's screenshot. This is especially prominent with the Page Area fill. Paragraph Area fill is not as hidden.

With KDE backend, the Recent colors in the Color tab have much smaller height.
Also with KDE, the Color tab has the Add Delete buttons clipped a bit from the bottom, when in Paragraph Area fill. Strangely, the Area fill for Page is fine in this regard.

Version: 5.4.0.0.alpha0+
Build ID: 2fd88ab1cbb4690a770ca2ca5d66157ec4906a2e
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
(built a moment ago)
Comment 10 Tomaz Vajngerl 2017-01-13 08:05:23 UTC
OK, now I know what is wrong. When the dialog is constructed it needs to calculate the optimal size of the content, but because we switch between the pages with buttons, we don't account for all pages but only the one that will currently be shown. Mostly this is the "None" page so it doesn't account anything and when we activate another page, the dialog will be too small and something will break.
Comment 11 Commit Notification 2017-01-13 13:06:14 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e6d7d737522124350a17a3cfdee055f03200a274

tdf#105259 calculate sizes of all area tab pages on construction

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Buovjaga 2017-01-13 14:17:06 UTC
The problems I mentioned in comment 9 are all gone (kde + gtk2 + gtk3 + gen).

Arch Linux 64-bit, KDE Plasma 5
Version: 5.4.0.0.alpha0+
Build ID: 57779b5f3a49fedd952aed70ddcce22f48b98ea5
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on January 13th 2016
Comment 13 Tomaz Vajngerl 2017-01-13 14:57:16 UTC
https://gerrit.libreoffice.org/#/c/33048/
Comment 14 Tomaz Vajngerl 2017-01-13 15:03:21 UTC
OK, so problem now is that some dialogs can be too big.. but this should be a new bug with lower priority.
Comment 15 Heiko Tietze 2017-01-13 18:04:12 UTC
Excellent work, Tomaz!
Comment 16 Heiko Tietze 2017-01-13 18:09:13 UTC
(In reply to Buovjaga from comment #12)
> The problems I mentioned in comment 9 are all gone (kde + gtk2 + gtk3 + gen).

Checked my build on Qt based host and on native gtk3 VM.
Comment 17 Commit Notification 2017-01-13 21:12:41 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9157ae95d4861c545b01e1d9df67932c86a3c640&h=libreoffice-5-3

tdf#105259 calculate sizes of all area tab pages on construction

It will be available in 5.3.0.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 18 Buovjaga 2017-01-14 13:56:17 UTC
Behaving OK in Ubuntu 16.10 as well
Version: 5.4.0.0.alpha0+
Build ID: ec1afa55e8ed79dc290caff74aaca304a77c3b4f
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF-dbg, Branch:master, Time: 2017-01-14_02:36:56
Locale: en-US (en_US.UTF-8); Calc: group

..and Win 10
Version: 5.4.0.0.alpha0+
Build ID: 9e7526044c8fa6b006b0cb791d15f2476c96ebf2
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-14_04:20:03
Locale: fi-FI (fi_FI); Calc: group

..and latest macOS Sierra
http://dev-builds.libreoffice.org/daily/master/MacOSX-x86_64@49-TDF/2017-01-14_04.23.59/