When you click a (typical) object like a text box, the Text Formatting toolbar appears. Similarly for tables and the Table toolbar. However, a user might not want this to happen. (Myself - it's very annoying for me that the slide moves slightly due to the toolbar reducing the viewport area; or how the toolbar hides some of the object.) Well, LO doesn't seem to allow you to give you the option of disabling this auto-appearance of these toolbars - neither specifically nor globally.
Somewhat related to bug 137757.
It seems this is also relevant to Writer, and perhaps other apps.
Seems to be a duplicate of the idea in Bug 106846 - CONFIGURATION: Means to enable and disable context-sensitive ability of toolbars
*** This bug has been marked as a duplicate of bug 106846 ***
On second thought, bug 106846 is one of several possible solutions here, not the exact same issue
(In reply to Eyal Rozenberg from comment #5) > On second thought, bug 106846 is one of several possible solutions here, not > the exact same issue Why? When you are disabling the context-sensitivity of a toolbar then it doesn't pop up.
(In reply to Thomas Lendo from comment #6) > Why? When you are disabling the context-sensitivity of a toolbar then it > doesn't pop up. That doesn't contradict what I said. There are other possible solutions, such as: * Context-sensitivity only causes appearance, never disappearance. * Different-scope setting: Global, per-app, per-document, per-page, per session (of running an LO app) * Widget for temporarily "locking" the toolbar layout from any changes etc
(In reply to Eyal Rozenberg from comment #7) > (In reply to Thomas Lendo from comment #6) > > Why? When you are disabling the context-sensitivity of a toolbar then it > > doesn't pop up. > > That doesn't contradict what I said. > > There are other possible solutions, such as: > > * Context-sensitivity only causes appearance, never disappearance. > * Different-scope setting: Global, per-app, per-document, per-page, per > session (of running an LO app) > * Widget for temporarily "locking" the toolbar layout from any changes > > etc Or, the solution provided via the MUFFIN hybrid 'Contextual Single' UI mode?
(In reply to V Stuart Foote from comment #8) I noticed you mentioned something named Muffin in bug 106846, but I didn't quite understand what you meant. Can you explain what that is / what that means?
(In reply to Eyal Rozenberg from comment #9) > (In reply to V Stuart Foote from comment #8) > > I noticed you mentioned something named Muffin in bug 106846, but I didn't > quite understand what you meant. Can you explain what that is / what that > means? Eyal, do you think that changing the user interface to Contextual Single (with View > User Interface...) covers this issue sufficiently?
(In reply to Eyal Rozenberg from comment #9) > (In reply to V Stuart Foote from comment #8) > > I noticed you mentioned something named Muffin in bug 106846, but I didn't > quite understand what you meant. Can you explain what that is / what that > means? MUFFIN [1-4] is the LibreOffice marketing word for GUI development in GTK UI using UNO controls which included the Notebook Bar and customization of the Sidebar Deck framework. The Contextual Single UI mode was hybrid XML TB and UI NB work by Maxim on bug 125040 intended to suppress annoyances of a contextual po-up of XML TB (bug 124835 as a partial solution to bug 106846) by appending the XML TB to a minimal UI single line NB. In sum it is one of the cleaner UI flavors (MUFFIN) that LO offers as alternative to traditional Menu & TB. =-ref-= [1] https://blog.documentfoundation.org/blog/2016/12/21/the-document-foundation-announces-the-muffin-a-new-tasty-user-interface-concept-for-libreoffice/ [2] https://wiki.documentfoundation.org/Design/Meetings/2016-01-15 [3] https://wiki.documentfoundation.org/Design/Meetings/2016-09-23 [4] https://wiki.documentfoundation.org/Design/Meetings/2019-05-09
(In reply to stragu from comment #10) > Eyal, do you think that changing the user interface to Contextual Single > (with View > User Interface...) covers this issue sufficiently? If I understood you correctly, then no, because: 1. Contextual Single is just one of several UI's (and not even the default one or the most popular). 2. The bug manifests in Contextual Single UI as well (that might be a separate bug actually; for example, why do I need to whole table toolbar to pop up automatically when I already get some of it in the main single contextual toolbar?)
(In reply to V Stuart Foote from comment #8) > Or, the solution provided via the MUFFIN hybrid 'Contextual Single' UI mode? Now that you've explained this - I can see that, in principle, that could be an alternative approach to having toolbars pop in and out of view. But that would mean completely disabling context-sensitivity of toolbars in the default UI mode and perhaps others. Is that something you want?
(In reply to Eyal Rozenberg from comment #13) > (In reply to V Stuart Foote from comment #8) > > Or, the solution provided via the MUFFIN hybrid 'Contextual Single' UI mode? > > Now that you've explained this - I can see that, in principle, that could be > an alternative approach to having toolbars pop in and out of view. It is and it is functional now, but does need additional dev attention, e.g. bug 142653. > But that > would mean completely disabling context-sensitivity of toolbars in the > default UI mode and perhaps others. Not at all, each is a specific UI selection that manages the contextual actions as designed/implemented. When you select Contextual Single, the UI is a Single toolbar that is recomposed depending on the object with actionable focus--it is contextual. The other UI modes would be unaffected. While in the 'Standard' UI traditional menu/TB/dialog UI the context sensitive TB will still pop-up either docked or floating as you've configured each. > Is that something you want? MUFFIN assemblages (menu/XML TB/XML & GTK UI Sidebar/GTK UI NB) give a mix of UI behaviors. Each treats the context sensitivity a bit differently. So yes.
(In reply to V Stuart Foote from comment #14) > Not at all, each is a specific UI selection that manages the contextual > actions as designed/implemented. Well, then, why did you suggest that as a potential solution? I'm confused. Anyway, regardless of other UI modes, and whether or not toolbar popping should be dropped in favor of their approaches - this bug is about the ability to prevent toolbars from auto-appearing, period. And the default UI sorely needs this as an option. So, (V Stuart Foote or anyone else) - please confirm the bug and mark it NEW.
(In reply to Eyal Rozenberg from comment #15) > (In reply to V Stuart Foote from comment #14) > > Not at all, each is a specific UI selection that manages the contextual > > actions as designed/implemented. > > Well, then, why did you suggest that as a potential solution? I'm confused. > > > Anyway, regardless of other UI modes, and whether or not toolbar popping > should be dropped in favor of their approaches - this bug is about the > ability to prevent toolbars from auto-appearing, period. And the default UI > sorely needs this as an option. > > So, (V Stuart Foote or anyone else) - please confirm the bug and mark it NEW. Nope, but I will mark it => WF and back to duplicate of bug 106846 *** This bug has been marked as a duplicate of bug 106846 ***
(In reply to V Stuart Foote from comment #16) > back to duplicate of bug 106846 The thing is, this issue was opened mentioning the bug that auto-appearance results in, while that issue is an enhancement. Seeing how the discussion here has veered elsewhere, would you be ok with me opening a different issue focusing _only_ the bugginess of the current situation, as a non-dupe?
(In reply to Eyal Rozenberg from comment #17) > (In reply to V Stuart Foote from comment #16) > > back to duplicate of bug 106846 > > The thing is, this issue was opened mentioning the bug that auto-appearance > results in, while that issue is an enhancement. Seeing how the discussion > here has veered elsewhere, would you be ok with me opening a different issue > focusing _only_ the bugginess of the current situation, as a non-dupe? No, how would that be different than bug 106946, or earlier bug 36976 and dupes. They are *all* about eliminating the viewport shift the contextual TBs cause when opening in docked position. That is *NOT* a bug. That is a facet of implementation, and changing it to do something different is an enhancement. The context sensitive behavior of Toolbars (or the Sidebar Deck, or the NB Toolbar) is hard coded deep in the source. Only how that signal is handled is controlled by the UI mode. Gaining control over that--via alternate UIs, or a control framework for context sensitive action for individual toolbars--requries the same dev work. Same goal of the dupes.
*** This bug has been marked as a duplicate of bug 38850 ***