Page 1 of 1

Toolbar moving woes

PostPosted: Mon Dec 03, 2018 10:18 pm
by anzon
I am trying to move a toolbar as per documentation.
I have plenty of space on the second row that i have of toolbars.
When I try to move and then release a toolbar in an empty patch on that second line, the toolbar insists on cramming up into the top line where it then shunts those, happily esconced and displaying beautifully, into abbreviated, diminished version of themselves.
Furthermore, that top line of toolbars is visually cut short when resizing the "windows" / frame in MacOs Mojave 10.14.1 running Chrome Version 70.0.3538.110 (Official Build) (64-bit) and using AOO413m1(Build:9783) - Rev. 1761381 2016-09-23 02:39:34 (Fri, 23 Sep 2016).
I know there is a newer version of OOCalc/ OO, but hey this is a good version for my little brain, and does everything else wonderfully.
Other behaviour / diagnostics
The toolbar chosen, and it seems not, so far, to matter which, happily exists in a floating mode, but will not dock as preferred.

Re: Toolbar moving woes

PostPosted: Mon Dec 03, 2018 11:25 pm
by Villeroy
anzon wrote:I know there is a newer version of OOCalc/ OO, but hey this is a good version for my little brain, and does everything else wonderfully.

In theory, 4.x should be more "advanced" than version 3.x but it is almost the same with some sugar coating.
4.0.x is the same program as 4.0.0 but with less bugs.
4.1.6 is the same program as 4.1.0 but with less bugs.

The first number should indicate major development leaps but does not since OpenOffice is a dead project walking.
The second number indicates minor improvements and additional features. However, you will not notice anything in the upcoming version 4.2.0 compared to any 4.1.x version unless you read the list of changes on the project home page. You will hardly notice anything new since version 3.6 of 2011 since OpenOffice is a dead project walking.
The third number always indicates that this version does not include any changes except bug fixes. x.y.6 is more like x.y.0 should have been in an ideal world.

I can't tell much about toolbars since I only use them for graphic stuff and hide all of them except for the standard one with the most important functions plus some of my own buttons.
Oh, they dock and undock when you double-click a grey area without button with the Ctrl key being pressed. When Ctrl+Dbl-Clicking, each one remembers its last position when docked or undocked respectively. And the "corrugated" left end serves as a handle for exact positioning. This handle can be turned on/off by the rightmost drop down menu on the right end.
If you want to permanently hide a toolbar, then you should use menu:View>Toolbars. Any other method hides it temporarily.

Re: Toolbar moving woes

PostPosted: Tue Dec 04, 2018 1:15 am
by MrProgrammer
anzon wrote:When I try to move and then release a toolbar in an empty patch on that second line, the toolbar insists on cramming up into the top line where it then shunts those, happily esconced and displaying beautifully, into abbreviated, diminished version of themselves.
I am unable to reproduce your problem. Toolbar positioning works fine for me on MacOS 10.11 and AOO 4.1.5. I don't run MacOS 10.14. You could see if the problem exists on the Guest User account ([Tutorial] Mac FAQ Q28/A28).

anzon wrote:The toolbar chosen, and it seems not, so far, to matter which, happily exists in a floating mode, but will not dock as preferred.
While floating you should be able to click the ▼ on the toolbar and select Dock Toolbar.

Villeroy wrote:I can't tell much about toolbars since I only use them for graphic stuff …. Oh, they dock and undock when you double-click a grey area without button with the Ctrl key being pressed.
I seldom use foolbars either. On a Mac you'll use the ⌘ key instead of Ctrl.

Re: Toolbar moving woes

PostPosted: Tue Dec 04, 2018 9:18 am
by anzon
The ⌘ double-click to undock is another neat way to also undock, as well as click-hold-drag on the vertical six dots on the left of a toolbar. To then dock a toolbar in a new position on a lower, new or second "line" is do-able close up to the left hand side of the frame, but not quite as close as the left position of the toolbar in the line above. The docking procedure volunteers to create an alternative vertical left hand side toolbar instead, if you go too close to the left of the frame's left edge. With a toolbar now positioned on a second line, no other tool bar is suffered to share that line, which is useful only if you want a very long edit box. The "lock toolbar position" toggle seems to help as the positioning neatens up and then extra toolbars can be put on a same line. So, is it a behaviour with multiple unlocked position toolbars?