Description: I am using Impress on a regular basis. One of the most annoying behaviour is so subtile that probably everybody is annoyed by it but nobody can exactly describe whats wrong. Il try: If a toolbar which is normaly invisble pops up then the document view is moved aside. Steps to Reproduce: 1. Fresh Libre Office installation 2. Create new Impress presentation 3. create a Table within the presentation => it already happend but you probably did not notice it: in the bottom the "table toolbar" appears. As a consequence the main window shrinked and the whole presentation moved up. Now the more annoying usecase: 4. deselect the table (=> "table toolbar" hides) 5. click inside the table to select it => "table toolbar" shows up again in the bottom which moves the table up. If you even clicked at the bottom of the table the table will even not be under the mouse cursor anymore when you release it because it moved away. Actual Results: Main Window drawing depends on visible toolbars. Expected Results: main Window drawing should be independant of toolbar appearance (like in MS Word when a ribbon is blended in/out). Reproducible: Always User Profile Reset: Yes Additional Info: The only known workaround i found googling is to create an empty dummy toolbar which is always visible in the bottom left. However the place of the empty toolbar is now wasted part of the screen. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Created attachment 140838 [details] screenshot of problem
Locking the frame of the presentation the canvas to a fixed scale is not an option. It is expected to respond as toolbars are opened and closed. However, any of the context sensitive toolbars can be undocked from the GUI. It will float at the position you place it when it is active. That use customization--opening toolbars and undocing/placing them as desired--is fundamental to the GUI.
You are arguing with Implementation details against the UI experience :-( It should just feel like the toolbars are on another level (just like in real when yoou put a paintbox on a paper the paper does not move away!). The implementation may be that the Canvas resizes but the x,y scrolling coordinated are translated so that the content does not move upon automatic resize of that Canvas. The best user feeling is when it is NOT needed to configure anything before it behaves like it should.
It behaves as implemented and so, NOTABUG. But poof! its an Enhancement request (we've seen similar on occasion, with bug 36976 still open to optionally modify contextual toolbar actions across the UI). "It should just feel like the toolbars are on another level..." So putting on my UX/Design hat, no _any_ context sensitive Toolbar can already be controlled in a consistent fashion by undocking and stateful placement--the user experience is fully customizable; we provide project defaults that make the most sense across the modules--toolbars docked by default at reasonable locations. My recommendation would be => WONTFIX
"It behaves as implemented and so, NOTABUG" Nothing can behaves other then implemented and so you just invented the nonexistence of bugs ;-) Unlike 36976 i dont want to disable toolbars. Toolbars should just behave user friendly (ok, call it feature request). Then no one would need to disable toolbars. Clicking on something should just never move that thing away (unless its a button which is obviously intended to open another dialog). For a better userexperience LO should learn from other UIs that work way better (MS Office for example)
(In reply to joerg.kubitz@gmx.de from comment #5) > "It behaves as implemented and so, NOTABUG" > Nothing can behaves other then implemented and so you just invented the > nonexistence of bugs ;-) No, that is simply our QA process--sorting out what are change requests of all flavors and merit, from legitimate errant behavior. And passing along either to our UX-Design process to look at the merits of the change. In objecting to what is already reasonable default GUI behavior, you are suggesting a major refactoring of the GUI for something that is already adequately addressed. With available dev cycles, this is just not a facet of the GUI that _requires_ any additional effort--requirements build/design or development. As the devs often refrain: patches are welcome.
May be there is a missunderstanding: I do not suggest putting the toolbars on another layer (like MS word does) just the interior of the editor canvas should not move when clicking inside it. Probably that could be fixed (or "changed") with two lines of code setting the x,y coordinates appropriate. I would contribute them if i could but unfortunalty i dont have the development environment todo so.
just one more word: the problem occurs in LO Impress. In LO Writer it works as i would intend (insert table, click inside, toolbar pops up but nothing moves) !
Apparently, Impress/Draw have a shared canvas while Write/Calc work differently. Not sure that this can be changed at all without rewriting all (-> needsdeveval). The simple solution is to make the TB floating or dock it at a place that never changes. The Notebookbar could become another solution.