This feature request relates to all forms of customized toolbars, Notebookbars, sidebar panels ... I will describe it using the example of toolbars.
- Writing text, the Formatting toolbar is shown.
- Clicking on a frame, the Formatting toolbar is replaced by the Frame toolbar.
- Clicking on a picture, the Formatting toolbar is replaced by the Frame and Image toolbars.
- But if you're using a separate, new, customized toolbar e.g. for text formatting then this toolbar won't be replaced by the Frame toolbar when clicking on a frame and back when clicking in a text. -- The new text toolbar and the Image toolbar will both be shown when clicking on a picture.
Not in every case you can customize the Formatting toolbar to fulfill his/her needs, e.g. with toolbars of extensions. Or in many good UI customization instructions it's preferred to make a own place for user needs instead of changing default configuration. Or it should be possible to switch between default Formatting toolbar and customized formatting toolbar, e.g. in company environments with different needs.
In a bar customization dialog it should be possible to anchor a bar (like context menus) to one or more specific objects. Choices (derived from the contest menu customization dialog): comment, form control, image, media, OLE object, print preview, shape, table, text, text frame.
A custom text formatting toolbar isn't necessary in the print preview, a custom image toolbar isn't necessary for texts.
Default bars shouldn't be editable so that users can't destroy anything.
Created attachment 132247 [details]
Dialog for contextual visibility of toolbars
See implementation of this as a useful, and probably necessary, control framework to support MUFFIN--but implementation correctly across the GUI would require a lot of refactoring.
IIUC existing contextual controls are not as modular as they would need to be to unify the behavior.
Design and UX aside, need some sense from devs as to scope/feasibility of the enhancement.
At least it's not UNCO.
(In reply to Thomas Lendo from comment #1)
> Created attachment 132247 [details]
> Dialog for contextual visibility of toolbars
Nice idea but unfortunately it wont be able to do what is needed.
Similar to setting the style of a toolbar, we need to be able to set the contextual nature of a toolbar. The contextual object types can be grabbed from here and here are their string equivalents. They will be presented in a drop down menu list and will alter the behaviour of the ContextSensitive attribute of toolbars when its set to anything other than the first entry - 'No'.
@Maxim, @mkara: Wasnt able to find anything in the code to tie the contextual behaviour of existing toolbars with the EnumContext values, as that would be the key part to make this issue work. Any thoughts?
Created attachment 132833 [details]
contextual field in customization dialog
(In reply to Yousuf Philips (jay) from comment #4)
> The contextual object types can be grabbed
> from here and here are their string equivalents. They will be
> presented in a drop down menu list
We also need to map contexts to applications, so e.g. pivot table context won't show in the list if opened from Writer.
> @Maxim, @mkara: Wasnt able to find anything in the code to tie the
> contextual behaviour of existing toolbars with the EnumContext values
There is no such code. Current handling of context toolbars predates EnumContext.
*** Bug 107851 has been marked as a duplicate of this bug. ***
(In reply to Yousuf Philips (jay) from comment #5)
> Created attachment 132833 [details]
> contextual field in customization dialog
How can toolbars assigned to more than one object in a drop down list, e.g. a single toolbar for frames and images?
(In reply to Thomas Lendo from comment #8)
> How can toolbars assigned to more than one object in a drop down list, e.g.
> a single toolbar for frames and images?
Yes it wouldnt be possible to have a single toolbar be used for multiple contexts in a drop down list, but ideally we should only have a single toolbar appear per context rather than 2 toolbars appear for a single context (e.g. bug 87362). One solution would be to have drop down list entries that had multiple contexts in it, e.g. 'frame, image, ole-object'.
Didn't have time to read everything, how is this different from bug 36976?
(In reply to Buovjaga from comment #10)
> Didn't have time to read everything, how is this different from bug 36976?
They are the same, but this has more substantive dev analysis of the issue(s), a bit of QA cleanup to dupe the older 36976 and friends to here... or not?
Hm, I thought this bug is about asigning a toolbar to any contextual behavior. The other one is to have the ability to stop/start the 'popping-up' of a contextual toolbar (but it should still be assigned to a special object).
*** Bug 125787 has been marked as a duplicate of this bug. ***
*** Bug 125816 has been marked as a duplicate of this bug. ***
*** Bug 127039 has been marked as a duplicate of this bug. ***
*** Bug 137760 has been marked as a duplicate of this bug. ***
While this feature in itself may be an enhancement, either this or another arrangement is significant in resolving a highly-annoying problem. Let me explain why (by repeating a point from my not-quite-dupe bug 137760):
An addition of a toolbar to the toolbar area resizes the viewport, and makes object in the viewport move. This is distracting when you're working on an object, e.g. a box in Impress, and you press it, expecting to type some text in - only for it to move away from where you pressed. You get the opposite effect when you click some other object - naturally only expecting it to become selected, not to move.
This phenomenon is doubly annoying if the viewport size change also affects the zoom level - which it might; and it is triply annoying if you have a "heavy" document, with numerous objects, as LO Impress or Draw often slow down significantly in the presence of these, and the redraws due to the viewport size change then take a long time.