Apache OpenOffice (AOO) Bugzilla – Issue 42072
only grey out inactive Toolbars
Last modified: 2013-08-07 14:38:26 UTC
The new behavior of toolbars, where they appear and disappear according to the characteristics of the current paragraph, is not very usable when the toolbars are docked at the top of the screen. As they pop in and out of existence, they cause the entire document to jump up and down by the height of a toolbar. if i click a paragraph that requires a toolbar change, the text under the mouse immediately jumps away. this is visually unappealing, and makes double or triple clicking a real pain. it would be _much_ more usable if the toolbars simply greyed out when they are not relevant to the active paragraph.
MRU->ES: please evaluate with resp. UserEx contact. IMO a good thing...
ES->CJ: It's an enhancement, but as this behaviour appeared with the new toolbars and IS REALLY enoying, I think we could regard it as a defect and try to fix it for OOo 2.0. What do you think?
CJ -> CD: The toolbar spec says that when a context sensitiv tb is docked it should not appear or disappear. please, compare with row 213 of the Toolbar Spec. Taking that, the current behaviour is a bug. Changed type to defect.
cd->cj: I think we need an additional meeting where we have to discuss a final solution for OOo 2.0. Your proposed solution would mean that a docked , context sensitive toolbar is not allowed to appear. After a restart of OOo no docked, context sensitive toolbar can be shown (not nice).
.
cd->cj: There will be a meeting on Friday where we discuss a solution for our toolbars. As I am unable to solve this, please take over and provide an updated spec which must be implemented.
I can see a few changes that would alleviate this problem in advance of a full spec fix: 1) Gentler defaults where possible. Example: Clicking a line removes the formatting toolbar, but adds the Drawing Object Properties toolbar to the right side of the standard toolbar. Instead, add it below the standard toolbar, where the formatting bar just disappeared from. This causes no jarring of the content area. 2) Scroll the document differently when adding toolbars. If a toolbar needs to appear docked at the top, scroll the visible document area down the exact height of the toolbar. In essence, keep the lowest visible area of the document still visible when a toolbar appears at top. The visual effect would be no apparent movement of document content, just reduced visible area where a toolbar "covered" some of the content. Do the opposite for toolbars that need to appear docked at bottom. This should also eliminate the jarring effect, and reduces the problem area to just what's covered by an appearing toolbar. If the cursor is in such an area, maybe it should be scrolled back into visibility. I'm not sure about what to do there.
started
*** Issue 43860 has been marked as a duplicate of this issue. ***
As discussed, this change will cause a very high testing effort. In addition changing the current behaviour is very risky. For assuring the time which is needed for testing for such fix we agreed to change the target from OO.o 2.0 to OO.o 2.01.
Taken from 43860: When context-sensitive toolbars are docked, their apprearance and disappearance causes the current page to be resized. This causes serious useablility problems for various situations. One example is for Form Design, in Writer. In form-edit-mode, when controls have focus, the Formatting toolbar (which is normally docked at the top of the page) is removed. This causes the entire page to jump up every time a control is selected. When editing a document containing a mixture of text and controls, this continual resizing becomes very tiring. Another example is in Draw. When a poly-line object is selected in Edit-Points mode, the "Line and Filling" toolbar is removed, causing the page to jump up. Again, this is very tiring for the user, to have their objects jump around in front of them. In OOo-1.1.x, this toolbar was automatically replaced by the Edit Points toolbar so resizing was avoided. One solution in this case is to have the Edit Points toolbar docked by default so whenever the Line&Fill toolbar is removed, it is replaced by a relevent alternative. The same issue occurs with glue-point edit mode, and the Gluepoints toolbar. Obviously, this problem is worse when large icons are used on a small display. However, "just use smaller icons" would not be a correct resolution for those of us with less-than-perfect eyesight! I guess the current behaviour meets the spec, so I must wait for the spec to be revised before we see any work to address this.
Me too: re earlier comments re page resizing, jarring effect - if you are going to turn toolbars on and off (I think this is bad practice but whatever) the display of the edited text should not change position. At the moment it changes position because the toolbar adds or removes space at the top of the screen. The text should stay static with the toolbar covering existing text at the top (or wherever) without the text being displaced by the appearance/disappearance of the toolbar. Also: the fact that context sensitivity of the toolbars overrides the user's choice to enable the toolbar is (IMO) nuts. If the user expressly turns the toolbar on it should stay on until they turn it off. Brendan
CJ: Changed target Office later
See also: Issue 46867
Any chance of re-targetting for at least the 2.X series, to keep this on the radar? Also, surely this is framework / ui? Cheers, Andrew (Note/ the two 'Started' duplicate issues- with CJ: Issue 42072 and with CD: Issue 46867)
*** Issue 91252 has been marked as a duplicate of this issue. ***
Context sensitivity of the toolbars has a big impact on the use of OOO on the netbook form factor. For small screens the visual impact of toolbars suddenly appearing is significant and wastes a large proportion of the available screen real estate. Please include a way for a user to turn off toolbar context sensitivity.
PS: A number of other toolbar related issues have been marked as duplicates of this issue. However, the proposed response ("only grey out inactive Toolbars") is not an appropriate solution for all issues marked as duplicates (see eg my note re netbook form factor above - greying out will still eat a big portion of the screen). The heart of the problem is the context sensitivity of toolbars and the inability for users to override (ie turn off) this (IMO mis-)behavior. The appropriate solution is to allow users to turn off context-sensitivity of toolbars. Example: From http://qa.openoffice.org/issues/show_bug.cgi?id=59706 I often have both numbered and unnumbered paragraphs in a document. If I am in a numbered paragraph the numbering toolbar is on. If I want to change a paragraph from unnumbered to numbered I click on the unnumbered paragraph - the numbering toolbar *disappears* - but I don't want it to disappear, I want it to stay there so I can apply numbering! Greying it out would present the same problem. btw - my workaround for this, to demonstrate how much pain this "feature" is for me, is to remove all icons from the numbering toolbar, dock it in the corner against one of the persistent toolbars and include the numbering icons in the formatting toolbar. It still turns on and off in the corner, but with minimal impact. I would like to do this with other context sensitive toolbars as well, but there's a limit to what can be absorbed in the more persistent toolbars.