Bug 34450 - UI: toolbars won't move first time docked on bottom (64bit)
Summary: UI: toolbars won't move first time docked on bottom (64bit)
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: x86-64 (AMD64) Linux (All)
: low trivial
Assignee: Caolán McNamara
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-18 06:53 UTC by sasha.libreoffice
Modified: 2021-03-18 09:14 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
config file of LibreOffice (deleted)
2011-04-18 01:59 UTC, sasha.libreoffice
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sasha.libreoffice 2011-02-18 06:53:01 UTC
On linux 64bit when toolbar docked on bottom edge on screen it is very hard to move it left or right. It not moves. 
On other screen edges toolbars moves ok. On windows 32bit toolbars on bottom of screen moves ok, but toooo slow.
Comment 1 sasha.libreoffice 2011-02-21 01:37:02 UTC
To reproduce this problem we need:
Close Libreoffice
go to ~/.libreoffice/3/user and delete file registrymodifications.xcu
start Libreoffice and create any document
enable "Drawing" toolbar ("Show Draw Functions" button on Standard toolbar)

Toolbar "Drawing" appears on bottom on screen, but I can not move it rightward or place other toolbar righthand to it.

To disappear this problem I move toolbar to center of screen and then back to bottom. Then this toolbar behaves ok.
Comment 2 sasha.libreoffice 2011-02-24 06:22:36 UTC
It is only Linux64 problem. On LibreOffice 3.3.1 still exist
Comment 3 Rainer Bielefeld Retired 2011-04-15 08:23:53 UTC
NOT reproducible with "LibreOffice 3.3.2  – WIN7  Home Premium  (64bit) German UI [OOO330m19 (Build:202 / tag 3.3.2.2)]".
Indeed only Linux or fixed in between?

@sasha:
Please contribute additional information concerning you Linux contribution and GUI.
Comment 4 sasha.libreoffice 2011-04-18 01:59:15 UTC
Created attachment 45756 [details]
config file of LibreOffice

This file is from Linux installation. To reproduce this problem on Windows, close Libreoffice, move original file registrymodifications.xcu to another save place and place file from attachment instead. (on my XP it holds in c:\Documents and Settings\{my login}\Application Data\LibreOffice\3\user\). Then start LibreOffice.
Toolbar "Draw" on bottom of screen not want to move horizontally and toolbar "find" if placed to right of "Draw"  do not want move.

I reproduced this problem on Fedora 64 bit with English UI.

As I can see, problem is somewere in registrymodifications.xcu, generated on Linux.
Comment 5 Kohei Yoshida 2011-04-18 13:31:24 UTC
I reproduced it.  And I'm on openSUSE 11.4 64-bit.

This only happens with a brand-new configuration (or if you've removed registrymodifications.xcu as the reporter suggested).

When the first time you show the 'Drawing' toolbar, it appears docked in the bottom of the window.  When you try to grab and move to the exact right, it won't move even after releasing the mouse button.  But once you drag out the tool bar into a floating position and re-dock it back to the bottom, you can move it horizontally.
Comment 6 Kohei Yoshida 2011-04-18 13:32:38 UTC
I don't know who the right person is for this bug, but Caolan is listed as the VCL expert, so I'll give this to Caolan.
Comment 7 Rainer Bielefeld Retired 2011-04-18 22:06:35 UTC
forgot to mention: I also tried the registrymodifications.xcu trick, but I was not able to reproduce the problem. That approves sasha's result that it's a Linux (64bit) problem.
Comment 8 LeMoyne Castle 2011-06-15 01:24:06 UTC
@5 Kohei gives workaround/solution: after floating will tbar move when docked and only occurs w/64bit -> importance to low-trivial
Comment 9 Caolán McNamara 2011-07-05 08:50:03 UTC
presumably this is due to the -1,-1 getting mangled somewhere
Comment 10 Caolán McNamara 2011-07-06 04:50:35 UTC
righteo, LONG_MAX is default value, but mangled into an int, which gives the same number on 32bit, but overflows in 64bit into an even stupider number, and it can't be moved properly.

fixed as http://cgit.freedesktop.org/libreoffice/libs-core/commit/?id=be46d6e8f0ede567b475152471041dc344d7cd63

will be in 3.5.0, not horrific enough for special 3.4.X handling IMO
Comment 11 Xisco Faulí 2018-02-26 11:20:33 UTC
The content of attachment 45756 [details] has been deleted
Comment 12 wilton 2021-03-17 06:19:02 UTC Comment hidden (spam)