Bug 38850 - In Tools > Options > View - add an option to control appearance of context-sensitive toolbars (on, off, automatic)
Summary: In Tools > Options > View - add an option to control appearance of context-se...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 34451 36976 45547 59176 61237 100314 105111 109291 119998 122030 125787 127039 137760 (view as bug list)
Depends on:
Blocks: Toolbars Bullet-Number-Outline-Lists
  Show dependency treegraph
 
Reported: 2011-06-30 12:15 UTC by wpiis
Modified: 2022-06-20 12:01 UTC (History)
20 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description wpiis 2011-06-30 12:15:21 UTC
The Bullets and Numbering toolbar disappears when not being used.
When I check View> Toolbars> Bullets and Numbering, the toolbar becomes visible.
I dock the Bullets and Numbering toolbar.
If I backspace on a line, deleting the Bullet/Number, the toolbar disappears which requires that I recheck the toolbar to make it visible again.

If I check view the toolbar (to make it visible) then the toolbar should remain visible until I uncheck it.
Thanks, Tracey
Comment 1 Björn Michaelsen 2011-12-23 12:25:25 UTC Comment hidden (obsolete)
Comment 2 Florian Reisinger 2012-08-14 14:00:56 UTC Comment hidden (obsolete)
Comment 3 Florian Reisinger 2012-08-14 14:02:02 UTC Comment hidden (obsolete)
Comment 4 Florian Reisinger 2012-08-14 14:06:43 UTC Comment hidden (obsolete)
Comment 5 Florian Reisinger 2012-08-14 14:08:45 UTC Comment hidden (obsolete)
Comment 6 sasha.libreoffice 2012-09-24 05:58:32 UTC
It looks like RFE bugreport. Reopening.
Comment 7 dhirenjani 2012-12-16 12:37:54 UTC
I can confirm this bug in LO 4.0beta1 on platform windows vista

Same behaviour is also seen for tables toolbar (it disappears when focus moves out from the table in any document)
Comment 8 Simo Kaupinmäki 2014-07-22 16:43:46 UTC
This issue is related to bug 34451 and apparently inherited from OOo.
Comment 9 Norbert X 2014-10-04 11:46:34 UTC
I can confirm this bug in 4.3.2.
I'll copy my comment from https://bugs.freedesktop.org/show_bug.cgi?id=81475#c23 here:

I think that dynamic appearance/disappearance of toolbars is not a good idea.

For me it is comfortable to place toolbars once and use them when I want to use them, not contextually (current object- or action- dependent).
But now in 4.3.2 toolbars disappear even if they have Lock Toolbar Position option checked. Please enable static toolbar positions. 

Popping toolbars may cause attention switch and may lower document author's productivity. Otherwise you will create another stupid, ugly, non-usable Ribbon/MFI. I think that many LibreOffice users would be happy with MS Office 2003-like interface.

Users do not need bells and whistles, they need comfortable and customizable interface. This interface should allow users to place and pin (lock) toolbars as they want and use keyboard shortcuts for more productivity (for example, the fastest way to add Cross-Reference is to press <Alt-i><e>).
Comment 10 Norbert X 2014-10-04 11:50:15 UTC
*** Bug 59176 has been marked as a duplicate of this bug. ***
Comment 11 Timi Agama 2021-10-12 11:15:17 UTC
This bug still exists as recently as LibreOffice 7.1.4.2 on Windows 10 x64.

And I'd argue that, from a user perspective, this is NOT the same bug as Bug 59176.

To recap (similar to original bug report):

1. Create a bulleted list
2. View -> Toolbars -> Bullets and Numbering
3. Move the cursor out of the list
4. Toolbar suddenly disappears

Basically, the toolbar only remains visible when you are within a list. As soon as you exit the list the toolbar disappears.

This is NOT the behaviour in LibreOffice Impress where the Bullets and Numbering toolbar automatically shows up when you are editing a bulleted list.

SUGGESTIONS
1. For uniformity across LibreOffice I'd suggest that the Impress behaviour should be implemented in Writer.
2. In addition, when the user selects the toolbar from the menu then it should never disappear - under any circumstances.
Comment 12 Heiko Tietze 2022-04-25 15:21:26 UTC
*** Bug 148673 has been marked as a duplicate of this bug. ***
Comment 13 Heiko Tietze 2022-04-25 15:25:41 UTC
As discussed on bug 148673 we should show the toolbar for any paragraph which outline level is not Text Body. And the toolbar should become renamed "Outline and List".
Comment 14 sdc.blanco 2022-04-25 21:21:37 UTC
(In reply to Heiko Tietze from comment #13)
> As discussed on bug 148673 we should show the toolbar for any paragraph
> which outline level is not Text Body. 
iiuc the OP here is about allowing the user to manually override the context-sensitive nature of the B&N toolbar. 

STR.

1. Insert a non-list paragraph.
2. View > Toolbars > Bullets and Numbering.
3. Insert a new paragraph, formatted as a list paragraph
4. Place cursor in (initial) non-list paragraph. 

Actual:    Toolbar appears after step 2, but disappears after step 4
Expected:  Toolbar remains visible (because I have manually chosen to "View" it) until I manually choose to "hide" it.

Tested with:
Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: f8e11c6480ff0005715b989a6d4e2e10a3816cf6

(I have not tested other context-sensitive toolbars, but I could imagine that the request can be generalized to "always show toolbars that I manually "activate" with View > Toolbars.)  

That request seems worthy of consideration, but the issue discussed in bug 148673 would not "resolve" the OP here -- because the B&N bar would disappear on non-list paragraphs with "Text Body" outline level.
Comment 15 Heiko Tietze 2022-04-26 07:40:50 UTC
(In reply to sdc.blanco from comment #14)
> .. the request can be generalized to "always show toolbars that I manually
> "activate" with View > Toolbars.)  

That's my understanding too. Somehow I manage this in my recent tests but I couldn't reproduce. Neither with the table toolbar. Fact is that leaving the context hides the contextual toolbar even when it was enabled manually.

But additional to this bug we should auto-show the list/outline toolbar more often. Which would be kind of a workaround to the other issue as it makes the manual activation obsolete.
Comment 16 sdc.blanco 2022-04-26 08:36:38 UTC
(In reply to Heiko Tietze from comment #15)
> Fact is....
Some do not like context-sensitive menus popping up (comment 9)
Others want to control toolbars manually, without it being overridden by context sensitivity (comment 0, comment 11)

If Tools > Options > Writer > View had a checkbox:  
    o Do not use context-sensitive toolbars 

Then I believe all the concerns in this ticket would be addressed, except for the new issue about outline and list, which I believe is incorrectly injected here.

And for the new issue, an Outline bar should be made separate from a List (B&N) bar.
- No other toolbar combines two different issues/functions. 
- Additional reasons available.
- Bug 148673 comment 7 elaborates how to make an Outline bar.
Comment 17 Heiko Tietze 2022-04-26 08:47:52 UTC
(In reply to sdc.blanco from comment #16)
> If Tools > Options > Writer > View had a checkbox:  
>     o Do not use context-sensitive toolbars 

Could be an option but I would prefer the tristate solution (on/off and automatic).

> Then I believe all the concerns in this ticket would be addressed, except
> for the new issue about outline and list, which I believe is incorrectly
> injected here.

Feel free to revert the duplication. 
 
> And for the new issue, an Outline bar should be made separate from a List
> (B&N) bar.

The toolbar offers Promote/Demote, Move up/down, and various list attributes. Makes no sense to separate one from the other.
Comment 18 sdc.blanco 2022-04-26 09:07:07 UTC
(In reply to Heiko Tietze from comment #17)
> prefer the tristate solution (on/off and automatic).
+1  - changing bug summary here

(In reply to Heiko Tietze from comment #15)
> But additional to this bug we should auto-show the list/outline toolbar more
> often. 
+1 -- which is the OP of bug 148673

> Which would be kind of a workaround to the other issue
But would not address the general concern here about controlling appearance of toolbars  

Last two points => reverting the dup of bug 148673
Comment 19 Telesto 2022-04-27 06:26:39 UTC
Bug 36976 looks like a duplicate (or visa versa)
Comment 20 Heiko Tietze 2022-04-27 08:04:18 UTC
*** Bug 100314 has been marked as a duplicate of this bug. ***
Comment 21 Heiko Tietze 2022-04-27 08:04:22 UTC
*** Bug 109291 has been marked as a duplicate of this bug. ***
Comment 22 Heiko Tietze 2022-04-27 08:04:27 UTC
*** Bug 119998 has been marked as a duplicate of this bug. ***
Comment 23 Heiko Tietze 2022-04-27 08:04:36 UTC
*** Bug 122030 has been marked as a duplicate of this bug. ***
Comment 24 Heiko Tietze 2022-04-27 08:05:17 UTC
*** Bug 36976 has been marked as a duplicate of this bug. ***
Comment 25 Heiko Tietze 2022-04-27 08:05:28 UTC
*** Bug 34451 has been marked as a duplicate of this bug. ***
Comment 26 Heiko Tietze 2022-04-27 08:05:38 UTC
*** Bug 45547 has been marked as a duplicate of this bug. ***
Comment 27 Heiko Tietze 2022-04-27 08:05:47 UTC
*** Bug 61237 has been marked as a duplicate of this bug. ***
Comment 28 Telesto 2022-04-27 08:08:14 UTC
Also Bug 106846 and duplicates requesting the same, I guess
Comment 29 Telesto 2022-04-27 09:37:00 UTC
*** Bug 137760 has been marked as a duplicate of this bug. ***
Comment 30 Telesto 2022-04-27 09:37:08 UTC
*** Bug 127039 has been marked as a duplicate of this bug. ***
Comment 31 Telesto 2022-04-27 09:37:14 UTC
*** Bug 125787 has been marked as a duplicate of this bug. ***
Comment 32 Telesto 2022-04-27 10:03:39 UTC
FWIW: on or off pretty binary. There tremendous amounts of toolbars. I'm not totally against context-sensitive toolbars in general. 

In my reading bug 106846 is actually asking for possibility to make customized toolbars context depended too (which I do even get)

However I do use only a selection of toolbars more often, and want those to be permanent. To prevent continues changes within the UI (with toolbar appears, disappearing etc). And certain controls in the toolbar have something a function even outside the context (which makes the disappear), another reason to have the non-context-sensitive

I have no problem with incidental context depended toolbars. If I would disable context-depended toolbars across the board, I would lack the controls at certain actions I incidentally use (and I might even overlook the existence of those)

So I actually prefer to have an entry similar to the 'lock toolbar position', except this entry called 'lock toolbar' (or Disable Context Sensitivity or whatever label fitting). This would give the maximum control.
Comment 33 sdc.blanco 2022-06-20 12:01:14 UTC
*** Bug 105111 has been marked as a duplicate of this bug. ***