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. Suggestion: 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[1] and here[2] are their string equivalents. They will be presented in a drop down menu list and will alter the behaviour of the ContextSensitive[3] 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? [1] http://opengrok.libreoffice.org/xref/core/include/vcl/EnumContext.hxx#64 [2] http://opengrok.libreoffice.org/xref/core/vcl/source/window/EnumContext.cxx#156 [3] http://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/UI/WriterWindowState.xcu#142
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[1] and here[2] 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.
As per my last comment, and with my blocked bug marked as a dupe of this one - marking this one as a normal-severity _bug_ rather than an enhancement.
How is this a bug? The view port shift is annoying--but the docked TBs opening contextually is exactly as the UI is implemented. You could set them docked and always showing--but you'd loose a lot of screen space. You could set them floating, but they'll pop-open over content you probably want to see. You can use the Sidebar UI which is contextual. You can use the Contextual Single UI whcih limits the context portion to a single fixed location. And I'll say now--those aren't "workarounds" they are what is implemented. What you can not do is disable the context sensitivity of the controls--that is the enhancement and even then it won't eliminate the viewport shift of exposing a docked TB.
(In reply to V Stuart Foote from comment #20) > How is this a bug? The view port shift is annoying--but the docked TBs > opening contextually is exactly as the UI is implemented. It is a bug in the design, not in the implementation. > You could set them docked and always showing No, I couldn't. If I set, say, the Table toolbar to be visible and docked in Impress, then click a table cell, then "leave" the table by clicking some other element - the Table toolbar disappears. Arguably, _that_ might be considered a bug in the implementation, but I'm not sure whether it's intended or unintended behavior. > You can use the Contextual Single UI which limits the context portion to a > single fixed location. 1. That doesn't help - the toolbars appear and disappear in that UI mode as well. 2. That doesn't help - because even if the appearance/disappearance had not manifested in Contextual Single UI mode - it is a whole other kettle of fish which many users dislike for various reasons. One UI mode is no panacea for issues with another UI mode, especially the default one.
(In reply to Eyal Rozenberg from comment #21) > (In reply to V Stuart Foote from comment #20) > > How is this a bug? The view port shift is annoying--but the docked TBs > > opening contextually is exactly as the UI is implemented. > > It is a bug in the design, not in the implementation. You can't just go moving the goalposts like this as it would mean losing a useful way of categorisation for no reason. This edit war stops now.
(In reply to Buovjaga from comment #22) > You can't just go moving the goalposts like this No goalposts are being moved. Bugs on this site are occasionally about the design rather than the implementation, and I have never seen this custom contested before. > as it would mean losing a useful way of categorisation for no reason. If the categories are "change how things are intended to work" vs "make things work the way they were intended", then like I said - this is not a categorization effected by the Severity field. An enhancement severity is used when "it would be better if", and other severities are used when there's something wrong with the existing state of affairs. > This edit war stops now. A "war" does not stop with someone making another "attack" and declaring it is the last. Generally, if you disagree with a good-faith edit, what should happen is an exchange of opinions and the reaching of an agreed state of the fields in question. If I was wrong in my edit, please convince me. Specifically regarding severity - differences of opinion should be settled on the side of non-enhancement. The reason is that if current behavior is seen is inappropriate/unacceptable by some, and merely sub-optimal by others, then it typically is, indeed, inappropriate/unacceptable for some - and thus not just an enhancement. I am suggesting somewhat of a compromise by marking the Severity as minor.
Most duplicates where asking for what's described in bug 38850, IMHO. What's being ask here (OP) appears to be different.