Description: With Writer "outline view" enabled. . . If a headline is short (like "Lorem Ipsum" at 14 points) and centered on a page of standard width (like 6 inches), I may have a hard time keeping the "folding outline" icon visible long enough to access it. I hover over the headline, the icon becomes visible, but by the time my mouse reaches the icon (at the left margin) the icon may have disappeared. I then have to hover over the precise place where the icon should be, and do so long enough for the icon to reappear. This kind of hide-and-seek behavior is awkward for the user. If I'm quick enough with my mouse, all is well. And that's usually the case. But I may not always be quick. If the headline is placed flush right (a less likely placement), the problem is more acute. Steps to Reproduce: 1.Enable "Writer outline view" 2.Create a document that includes a short headline (say "Lorem Ispum" with heading style 3, 14 points) 3.Center the headline (or make it flush right) 4. Hover over the headline, or click on it, until the "folding outline" icon appears. 5. Move the mouse towards the icon. Actual Results: By the time the cursor reaches the place where the icon should be, the icon may still be there or may have disappeared, depending on how fast I get there. If it disappears I have to try again or try to move my mouse over the place where the icon was until the icon reappears. Expected Results: The icon should stay steadily visible long enough to be reached and acted upon. Alternatively, perhaps the icon should be placed adjacent to the headline, just to its left. This may be the more elegant solution. Reproducible: Sometimes User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 7.1.0.3 / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Flatpak Calc: threaded
I tried adding "Writer-Outline-View" to "Blocks," as instructed at Bug 38093, but got this response: "'Writer-Outline-View' is not a valid bug number nor an alias to a bug."
Holding the Ctrl key while the mouse is positioned on the heading will change the pointer to a hand pointer. Then left-click to toggle visibility of content from selected heading to next heading. Right-click to hide or show all content from selected heading (and all its subheadings) to next heading at same outline level. Here is a link to the help page for this: https://help.libreoffice.org/latest/en-US/text/swriter/01/outlinecontent_visibility.html?DbPAR=WRITER#bm_id861604659229058b >Expected Results: >The icon should stay steadily visible long enough to be reached and acted upon. The icon is removed when the mouse goes out of the heading frame. It is not a timer that determines this. The mouse does not need to be over the text. The frame extends the width of the page. Moving the mouse near where the icon appears will reveal it. >Alternatively, perhaps the icon should be placed adjacent to the headline, just >to its left. Or to the right for RTL users. >This may be the more elegant solution. Thanks for the suggestion. I will look into doing it.
Thank you for the link to the help page. Invaluable. I'm grateful for your well thought-out and well implemented work.
Created attachment 170465 [details] buttons near text and RTL placement In this patch the outline content visibility buttons are made to show near the position of the heading text and to also account for RTL paragraphs: https://gerrit.libreoffice.org/c/core/+/112463
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/48570b9b5e4939069f8a1a2541fd4efe6f2bb0aa tdf#140892 Outline Content Visibility Window button improvements It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 170678 [details] demo of outline folding buttons sized the height of outline heading frame Button placement is a bit unexpected for paragraphs with center alignment and a list style. The numbering or bullet gets covered by the button. Attached is a demo showing the buttons having the height of their outline heading frame. This makes buttons resize to the document zoom factor. It also shows labeling changes made for the enhance request in bug 141102. Improvement?
Improvement? I'd say so, for sure. In the labels on the toolbar, "Toggle Outline Folding" is fine (though maybe it ought to be sentence case). But in "Show outline folding buttons" we need a hyphen: "outline-folding buttons." (That's because here "outline-folding" acts as a compound adjective, modifying "buttons." [Grammar Monster: https://tinyurl.com/compound-adj].)
(In reply to j.a.swami from comment #7) > Improvement? I'd say so, for sure. > > In the labels on the toolbar, "Toggle Outline Folding" is fine (though maybe > it ought to be sentence case). But in "Show outline folding buttons" we need > a hyphen: "outline-folding buttons." > > (That's because here "outline-folding" acts as a compound adjective, > modifying "buttons." [Grammar Monster: https://tinyurl.com/compound-adj].) I'll make that change. What about the 'toggle outline' in the button tool tip 'Click to toggle outline folding' should there be a hyphen here?
Your tool tip is perfect as is. No hyphen needed.
Link to a patch that makes the fold button height the same height as the outline heading frame. https://gerrit.libreoffice.org/c/core/+/113142
On further thought, two points: 1. The backgrounds of the buttons might benefit from having a tint that's a bit lighter, so as to stand out less. (The writer most wants to focus on the words.) 2. At one time we had a down-arrow button and a sideways-arrow button. Now the arrows are up and down. Perhaps because the buttons are now larger and more conspicuous, I find this a bit confusing. For two reasons. First, such arrows might seem to be meant to move subheads up or down. We quickly learn this isn't what they're for. But the impression may still linger. Second, what does an up arrow mean? Does it mean the text is already up, or does it mean there's text I can pull up? Similarly for the down arrow: text already down or text I can drop down? Again, one will quickly learn. But better to have greater clarity at the start and not even have to think about it. I think the sideways arrow works better to signify collapsed text (even if we use the same icon for both LTR and RTL). Then we have no questions about up or down. Text is either down or collapsed.
Created attachment 170778 [details] screenshot of plus and minus button use (In reply to j.a.swami from comment #11) > On further thought, two points: > > 1. The backgrounds of the buttons might benefit from having a tint that's a > bit lighter, so as to stand out less. (The writer most wants to focus on the > words.) Let's make this a separate enhancement request. > > 2. At one time we had a down-arrow button and a sideways-arrow button. Now > the arrows are up and down. Perhaps because the buttons are now larger and > more conspicuous, I find this a bit confusing. For two reasons. > > First, such arrows might seem to be meant to move subheads up or down. We > quickly learn this isn't what they're for. But the impression may still > linger. > > Second, what does an up arrow mean? Does it mean the text is already up, or > does it mean there's text I can pull up? Similarly for the down arrow: text > already down or text I can drop down? Again, one will quickly learn. But > better to have greater clarity at the start and not even have to think about > it. > > I think the sideways arrow works better to signify collapsed text (even if > we use the same icon for both LTR and RTL). Then we have no questions about > up or down. Text is either down or collapsed. Maybe + and - symbols would work. Please see the screen shot example of this. I have no problem with right-arrow and down-arrow if you feel those are better suited for the purpose.
(In reply to Jim Raykowski from comment #12) > (In reply to j.a.swami from comment #11) > > > > 1. The backgrounds of the buttons might benefit from having a tint that's a > > bit lighter, so as to stand out less. (The writer most wants to focus on the > > words.) > Let's make this a separate enhancement request. Done. > > > > > 2. At one time we had a down-arrow button and a sideways-arrow button. Now > > the arrows are up and down. Perhaps because the buttons are now larger and > > more conspicuous, I find this a bit confusing. For two reasons. > > > > First, such arrows might seem to be meant to move subheads up or down. We > > quickly learn this isn't what they're for. But the impression may still > > linger. > > > > Second, what does an up arrow mean? Does it mean the text is already up, or > > does it mean there's text I can pull up? Similarly for the down arrow: text > > already down or text I can drop down? Again, one will quickly learn. But > > better to have greater clarity at the start and not even have to think about > > it. > > > > I think the sideways arrow works better to signify collapsed text (even if > > we use the same icon for both LTR and RTL). Then we have no questions about > > up or down. Text is either down or collapsed. > Maybe + and - symbols would work. Please see the screen shot example of this. > > I have no problem with right-arrow and down-arrow if you feel those are > better suited for the purpose. I think right-arrow and down-arrow do work better. The + and - symbols have the same issue as up- and down-arrows -- the user may likely be confused about what they mean. By the way: MS-Word in outline mode plays a different game: A heading or subhead that has text beneath it is marked by a button with a + sign, regardless of whether or not that text is collapsed. And a head or subhead with nothing beneath it has a button with a - sign. That works well. But it seems to me that the way you've done it, with right-arrow and down-arrow, is just as good, and perhaps better.
(In reply to j.a.swami from comment #13) > I think right-arrow and down-arrow do work better. The + and - symbols have > the same issue as up- and down-arrows -- the user may likely be confused > about what they mean. Thanks for the thoughts on the symbols to use. I will revert them to right-arrow and down-arrow. Should the button height be the height of the frame and placed in the margin, or just leave them the size they are now with position close to the alignment of the text? I've had no success in accommodating for bullet or numbering. A fix to make the fold button not hide then show when the mouse pointer leaves the button is on the way.
(In reply to Jim Raykowski from comment #14) > Should the button height be the height of the frame and placed in the > margin, or just leave them the size they are now with position close to the > alignment of the text? Having looked more at both ways, I'd go for the size they are now and aligned close to the text. Neater, less dominating. (And then my just-filed bug report 141328, about the tint for the buttons, will be needless and can be closed.) > I've had no success in accommodating for bullet or > numbering. Yes, that's an issue I noticed also. Perhaps a solution will bubble up to the surface. > A fix to make the fold button not hide then show when the mouse > pointer leaves the button is on the way. Splendid. Thank you so much again.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c41a188086c8b570b663183cbc1b0a033e5a2358 tdf#140892 Revert outline fold button symbols to right and down arrows It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
A polite ping to Jim Raykowski: Is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Otherwise, Could you please explain what's missing? Thanks
There is still a problem with accommodating for bullet or numbering that I would like to resolve before marking this as fixed.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/589cfd3ef33ddb42ea265e2ab2b87d32f1f1f67d tdf#140892 Account for list bullets and numbering It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The above patch places the fold button before list bullets/numbers as long as the paragraph alignment is set left for LTR or right for RTL. If the alignment is set otherwise, the button is placed at the position as if the alignment was not applied. Poked around SwParaPortion and various layout related rects without success in being able to make the button appear before the bullet/number in this case.