Download it now!
Bug 78924 - UI: Regression: toolbars have different heights
Summary: UI: Regression: toolbars have different heights
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.1.4.2 release
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA needsKDE target:5.4.0
Keywords: possibleRegression
: 73779 (view as bug list)
Depends on:
Blocks: KDE
  Show dependency treegraph
 
Reported: 2014-05-19 19:54 UTC by sergio.callegari
Modified: 2020-02-17 19:20 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Image Showing Good Toolbar Height (283.48 KB, image/png)
2014-05-20 03:02 UTC, Joel Madero
Details
Snapshot montage showing the different toolbar height (164.17 KB, application/pdf)
2014-05-21 06:27 UTC, sergio.callegari
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sergio.callegari 2014-05-19 19:54:30 UTC
Issue also affects impress in addition to draw.

Issue has been tested with the kde integration and without the gnome integration packages on kubuntu 14.04, using the libreoffice packages distributed on the libreoffice site (not the distro ones).

Problem description:

Since LibO 4.2 the 'line and filling toolbar' and the 'text formatting toolbar' have slightly different heights (maybe 1-2 pixels).  Up to LibO 4.1 all toolbars had exactly the same height.

As a consequence, when one needs to draw something that is just a bit complex, the drawing continuously jumps up and down by a few pixels, whenever one selects or unselects text. This is very annoying, you feel like trying to prepare a drawing while standing on the tube since the pictures moves under your eyes.

The issue is present with the automatic and small settings for the icon sizes and not with the large icon size.

I suspect that it may also manifest differently depending on the screen resolution, etc.  However, my point of view is that the toolbars should have a fixed height, no matter what.
Operating System: Ubuntu
Version: 4.2.0.4 release
Last worked in: 4.1.6.2 release
Comment 1 Joel Madero 2014-05-20 03:02:12 UTC
Cannot confirm - 

Ubuntu x64
LibreOfficeDev 4.5 daily build

Image attached. Please test with 4.2.4 (not sure why you're still on 4.2.0). Also - it's always recommended to use a ppa with Ubuntu/Kubuntu - https://launchpad.net/~libreoffice/+archive/libreoffice-4-2

The package is NOT the same as the one on libreoffice.org. Install that ppa, pure libreoffice, install libreoffice (you'll have 4.2.4) and then test again. If you can still reproduce - give us a good screenshot with some magnifying program showing the toolbars and mark the bug as UNCONFIRMED. Thanks
Comment 2 Joel Madero 2014-05-20 03:02:37 UTC
Created attachment 99373 [details]
Image Showing Good Toolbar Height
Comment 3 sergio.callegari 2014-05-21 06:25:51 UTC
Actually, I am on 4.2.4.2.  In the bug report I filled in the first version of LibO in which the bug appeared.

Tested with LibO from libreoffice.org to make sure it was not due to ubuntu build.

As mentioned, bug appearance depends on the combination of DPI and icon size you use, which is why you may not be able to see it. The point is that LibO 4.1 never showed this issue at any DPI and icon size and does not show the issue when run on the same machine, with the same config.

I am making the bug visible with a couple of screenshots. The attached picture is a montage of two screenshots made with the print screen functionality. Montage is done with imagemagick to assure that the images are aligned to the pixel. Montage is then imported into an image editor itself, in order to add a couple of horizontal and vertical red lines that help noticing the skew in the drawing canvas positioning due to the different toolbar height.

Specifically, screenshot A is taken with line and filling toolbar, screenshot B after selecting text in order to make the text formatting toolbar substitute the line toolbar and filling.  Screenshots A and B are then mounted as

A B
B

This lets both the horizontal and the vertical alignments be checked.  Red reference lines are placed around the toolbar and at the edges of the letter 'T' in the drawing canvas.

As evident, the text formatting toolbar is two pixels taller than the line and formatting toolbar. As a result, when the text is selected and the text formatting toolbar appears, the text itself jumps down two pixels, when text is deselected, the text jumps back up two pixels.

Now, two pixels may seem like nothing. But when you are trying to do precision aliments and you frequently alternate text and non text selections, having the image moving up and down even by two pixels is an issue that makes you go back to LibO 4.1 immediately, regardless of the other advantages that LibO 4.2 may have.
Comment 4 sergio.callegari 2014-05-21 06:27:13 UTC
Created attachment 99470 [details]
Snapshot montage showing the different toolbar height
Comment 5 Joel Madero 2014-05-21 14:55:58 UTC
Version is the oldest version not latest. We just leave comments if the bug still exists on later versions.
Comment 6 sergio.callegari 2014-06-25 10:07:34 UTC
Can someone try this configuring the screen on linux at different resolutions?

In my case, it looks like the issue impact is different at different resolutions.

For instance:
96dpi -> almost negligible
120dpi -> visible
125dpi -> more visible

so, can anyone please try the following on linux kde?

1) configure kde for 125 dpi (settings->application appearance->fonts->force dpi)
  or even some absurdly large dpi such as 195
2) configure libreoffice for small toolbars
3) libreoffice --draw
4) add a text box with some text in it. Add a rectangle.
5) switch between text selection and rectangle selection
6) see if the page area moves during the switch.
Comment 7 Daniel Pastushchak 2014-12-12 18:11:17 UTC
Bug reprodused.  I'm using Ubuntu 14.10 with KDE(4.14.1) and LibreOfficeDev Version: 4.5.0.0.alpha0+
Build ID: dad173d9588e6abc2a465198b7d2881d4629246a
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-12-10_22:53:28
Comment 8 Buovjaga 2014-12-12 18:41:08 UTC
Setting to NEW per comment 7.
Comment 9 MarjaE 2015-07-08 19:55:16 UTC
Encountering this in 4.4.4.3.

Did not encounter this before.

It means if I select one thing, the whole drawing moves, and if I try to select two things, I may not select the right two things. Major usability bug.
Comment 10 MarjaE 2015-07-12 20:52:32 UTC
*** Bug 73779 has been marked as a duplicate of this bug. ***
Comment 11 MarjaE 2015-07-12 20:55:10 UTC
Bug 73779 reports the same problem in 4.1.4.2. Which pushes the earliest affected version back.
Comment 12 Robinson Tryon (qubit) 2015-12-09 18:28:54 UTC Comment hidden (obsolete)
Comment 13 sergio.callegari 2016-02-01 12:04:32 UTC
I'm seeing this again in 5.1.0.3 while LibO 5.0.5.1 does not have the issue on the same machine.

In draw, the "line and filling toolbar" is higher than the other toolbars (e.g. the "standard" toolbar).

This makes editing drawings extremely annoying whenever the toolbar is docked at the top.

Depending on which graphical element you click on, the toolbar appears or disappears, making the whole drawing jump up and down by a few pixels.



Machine runs Kubuntu Linux 15.10.
Comment 14 sergio.callegari 2016-02-16 14:58:21 UTC
5.1 and 5.1.1 RC 1 both have the issue.

The issue is bad enough to make working on draw/impress extremely tiresome to the eyes, to the point that sticking with version 5.0 is the only way to have work done.

Tried removing individual elements from the toolbar with "customize toolbar" leaving only buttons, as I had the expectation that it was the textual or dropdown items causing the issue, but it did not make any difference.
Comment 15 sergio.callegari 2016-02-17 19:02:47 UTC
Regression is solved by removing the KDE integration package.
Comment 16 sergio.callegari 2016-02-20 15:43:53 UTC
I have made some more checks on this. The item does not affect all of my machines. I have one of them that does not show the issue, even if the configuration is very similar to the others. Maybe the issue is not triggered on all screen resolutions / font sets.
Comment 17 MarjaE 2016-04-27 01:01:35 UTC
Affects OS X in 5.1.1.3.
Comment 18 MarjaE 2016-04-27 01:10:35 UTC
In OS X, the "Line and Filling" toolbar keeps disappearing, especially when I select text, sometimes other times, so it's not a different toolbs have different heights issue as "how do I keep the toolbar from disappearing?" Everything jumps up and down. I am getting a migraine, and need some way to keep things from jumping up and down.
Comment 19 MarjaE 2016-04-27 01:17:13 UTC
Is it possible to include a space, at the top of the window, for one or two toolbars? This would keep toolbars from moving the drawing when they appear/disappear.
Comment 20 Joel Madero 2016-04-27 05:04:10 UTC
(In reply to MarjaE from comment #19)
> Is it possible to include a space, at the top of the window, for one or two
> toolbars? This would keep toolbars from moving the drawing when they
> appear/disappear.

Please don't conflate issues. Write new enhancement requests for these types of things (last comment also). Thanks
Comment 21 Commit Notification 2016-12-20 13:22:29 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

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

tdf#78924 KDE4 drop special Combobox code

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 22 Xisco Faulí 2017-03-01 11:11:23 UTC Comment hidden (obsolete)
Comment 23 Xisco Faulí 2017-11-05 21:59:25 UTC
A polite ping to Jan-Marek Glogowski: is this bug fixed? if so, could you please
close it as RESOLVED FIXED ? Thanks
Comment 24 QA Administrators 2018-11-06 03:56:53 UTC Comment hidden (obsolete)
Comment 25 Buovjaga 2019-01-01 19:00:19 UTC
(In reply to sergio.callegari from comment #13)
> I'm seeing this again in 5.1.0.3 while LibO 5.0.5.1 does not have the issue
> on the same machine.
> 
> In draw, the "line and filling toolbar" is higher than the other toolbars
> (e.g. the "standard" toolbar).
> 
> This makes editing drawings extremely annoying whenever the toolbar is
> docked at the top.
> 
> Depending on which graphical element you click on, the toolbar appears or
> disappears, making the whole drawing jump up and down by a few pixels.

Can repro with the new kde5 backend.

Activate View - Toolbars - Text formatting. Drag it under the Standard toolbar.
Activate View - Toolbars - Line and filling. Drag it to the bottom.

Now focusing back and forth to the text in a text box and shape selection, the Text formatting and Line and filling toolbars appear depending on your focus.

The Line and filling toolbar is clearly higher than Text formatting.

Arch Linux 64-bit
Version: 6.3.0.0.alpha0+
Build ID: 2c7b0030b40de00e8c9ab997bdfe83631861968a
CPU threads: 8; OS: Linux 4.20; UI render: default; VCL: kde5; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 1 January 2019
Comment 26 Michael Weghorn 2020-02-17 10:49:29 UTC
(In reply to Buovjaga from comment #25)
> Can repro with the new kde5 backend.
> 
> Activate View - Toolbars - Text formatting. Drag it under the Standard
> toolbar.
> Activate View - Toolbars - Line and filling. Drag it to the bottom.
> 
> Now focusing back and forth to the text in a text box and shape selection,
> the Text formatting and Line and filling toolbars appear depending on your
> focus.
> 
> The Line and filling toolbar is clearly higher than Text formatting.
> 
> Arch Linux 64-bit
> Version: 6.3.0.0.alpha0+
> Build ID: 2c7b0030b40de00e8c9ab997bdfe83631861968a
> CPU threads: 8; OS: Linux 4.20; UI render: default; VCL: kde5; 
> Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
> Calc: threaded
> Built on 1 January 2019

Is that still the case? If so, can you attach a screencast that shows the issue?
I seem to be unable to reproduce on Debian testing with

Version: 7.0.0.0.alpha0+
Build ID: 718f540fb63af27c1336f89213444e9af753b8a9
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded
Comment 27 Buovjaga 2020-02-17 19:20:24 UTC
Well, the behaviour has changed in that after Text formatting disappears, it does not come back!

Let's close I guess.