summaryrefslogtreecommitdiff
path: root/sw/qa/extras
diff options
context:
space:
mode:
authorJustin Luth <jluth@mail.com>2023-05-22 13:28:55 -0400
committerJustin Luth <jluth@mail.com>2023-05-23 17:45:33 +0200
commitdce8d2dbc48eb1c7597afec236dc51b4b8aede9c (patch)
tree384702b059884b29d03282250b1f8a5bd89b52ad /sw/qa/extras
parent807ad65661c122a33fccb4fd3453ef92c0e9129d (diff)
tdf#140557 notebookbar: be smarter about hidden window size
This fixes a 7.1 regression from 53d73d532281b6734a7d4614bb74fc6cc15510f0 where notebookbar controls were being hidden (and then shown after a refresh of the toolbar), leaving big empty gaps. I don't know anything about vcl or window layout idiosyncracies, so I just read through this code looking for some way to fix the problem of the notebookbar not using all of its available space. The problem was that GetOutputSizePixel was returning zero. Why that would be I don't know. Perhaps because it had never actually been displayed on screen yet? (This was occurring on simply loading Calc.) Substituting a small DUMMY_WIDTH didn't give a very accurate reduction, so there was no space to add back in any items later on. When adding it back, it adds using a legitimate-seeming width, with an (unused this time) fallback to DUMMY_WIDTH. So, unless getLayoutRequisition cannot be depended upon for returning an accurate size, this should be a nice fix. It will no longer hide too many controls from the notebookbar. Change-Id: I1c39fe3532dad501c16f53612f8e26835b72638a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152125 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Diffstat (limited to 'sw/qa/extras')
0 files changed, 0 insertions, 0 deletions