Description: To make full use of the folding-outline feature, users should be able to specify, from within the canvas and at any time, the level to which all the text in a document will be collapsed. This helps users organize their content. And it also matters for printing and searching because text hidden by outline folding does not print and is not included in searches. I would envision that this feature could be made available through context-menu entries assigned to subheads (that is, to all paragraphs that have a non-zero outline level). The context menu could include entries like these: Outline folding: ▪ Show / Hide content below [for content below the present subhead] ▪ Hide all content below level [X] [that is, the same level the subhead is on, with the option to change "X" to any number from 1 through 10. “X” could default – visibly – to the present level.] Steps to Reproduce: Enhancement request. No problem. Actual Results: Enhancement request. No problem. Expected Results: See "Description" above. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: dbd4110cc36011042c98549d997daa79e8065aba CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-05-13_01:08:22 Calc: threaded
With video attachment 168404 [details] from bug 138136, maybe this would mean to add "up to level X" below "Include sub levels".
Let's ask design-team and Jim Raykowski. cc: Design-Team, Jim Raykowski
Sounds like a reasonable request. And +1 to the context menu idea rather than any shortcut like alt+<num>.
Created attachment 182893 [details] Fold all content of outline-level RFC demo1 (In reply to j.a.swami from comment #0) > The context menu could include entries like these: > > Outline folding: > ▪ Show / Hide content below > [for content below the present subhead] There is the Toggle Outline Folding UNO that does this that can be added to context menus and toolbars. > ▪ Hide all content below level [X] > [that is, the same level the subhead is on, with the option to change > "X" to any number from 1 through 10. “X” could default – visibly – > to > the present level.] Attached is a demo for comments.
Beautiful. The tip for "level 0" is especially useful. The label for the UNO function "Fold All Content Of Ouline Level" could be clearer. I suggest: "Fold all outline content to level." (I'd say "specified level," but that seems too long.) Many thanks!
(In reply to j.a.swami from comment #5) > The label for the UNO function "Fold All Content Of Ouline Level" could be > clearer. I suggest: "Fold all outline content to level." (I'd say "specified > level," but that seems too long.) '...to level' gives me the impression all outline content currently folded should be made visible/unfolded before the new fold to level is applied. As the patch stands now, the level specified does not affect outline content currently folded. I originally had "Fold all outline content below level...", similar to the suggestion made in your OP. No trouble to change things. Just need some clarification.
Well, first we need to make sure we all have the same understanding of what the function is supposed to do. So let’s check. First: I think we agree about what the existing UNO function is supposed to do (“Show / Hide content below”). So that only leaves. . . Second: “▪ Hide all content below level [X].” This is my understanding of what we want to have happen: 1. As shown in the demo, the user clicks the context-menu option now labeled “"Fold All Content Of Outline Level.” 2. Again as in the demo, a dialogue appears, offering the user the chance to specify any level, 0-10. 3. The user specifies a level – let’s say “3.” 4. Throughout the entire document, all the subheads for levels 3 and above (1, 2, and 3) will be visible. And – again, throughout-- the subheads for levels 4 and below (5, 6, 7. . .) will be hidden. Now, thinking further: We need to decide what will happen with content that doesn’t *have* a level. Beneath a subhead we might have some text, a chart, or what have you. And this, from what I understand, is all “no-level content.” Before, I was thinking that when we show a subhead we should show the content beneath it. But on further thought I think a better behavior would be to hide all such content in the document and just show the subheads, to the level specified. So when I specify a level—1, 2, 3, or whatever—all content other than subheads, throughout the document, is hidden. Then all I see is an outline of subheads, at whatever depth I specify. (And wherever I want to see underlying content, I can show it, using the already-existing UNO command.) This approach would give a clean outline to look at. It’s simple and intuitive. And it’s what users migrating to LO from elsewhere may already be used to. So that seems the best approach me. How does it seem to you? Also, the folks at Redmond (bless their profit-seeking hearts) have assigned to the command an eminently simple label: “Show Level” (followed by a choice box). Brilliant PS: Jim Raykowski wrote: >'...to level' gives me the impression all outline content currently folded should be made visible/unfolded before the new fold to level is applied. As mentioned above, I suggest we hide *all* content – everything apart from subheads. and >As the patch stands now, the level specified does not affect outline content currently folded. Understood. Again, I suggest that all non-subhead content be folded.
Created attachment 183037 [details] visualization of described expectation Is what is shown in the attached screen shot what we are going for? Seems setting the 'Headings level shown' in the Navigator content tree sort of already does this.
(In reply to Jim Raykowski from comment #8) > > Is what is shown in the attached screen shot what we are going for? I'd say so. Exactly what I have in mind. > Seems > setting the 'Headings level shown' in the Navigator content tree sort of > already does this. I confess to being lost in the Navigator. I gather I'm meant to do this: 1. Navigate to "Headings." 2. Click the down-arrow next to the stand-alone "H." 3. Select a number. But when I do that I get inconsistent results. For me, choosing a number does not consistently result in showing me the headlines up to the level I've chosen. And in any case, the folding or unfolding of levels in the Navigator seems to pertain only to the tree shown in the Navigator itself. It doesn't seem to affect what is displayed in the actual document. But again: The attached screen shot looks perfect.
Created attachment 183214 [details] video demo outline levels shown 1 Here is a patch that seems to be what we are after: https://gerrit.libreoffice.org/c/core/+/141678 Does this look right j?
Everything on the canvas seems as expected, with one exception: At 1:38 I don't understand why unfolding everything (in the canvas) to level 5 also displays the (no-level) text under level 3. I would have thought that this text would remain undisplayed and all we would see would be the subheads at all levels up through 5. I do have some other questions, though. First, in "Options" (at the start of the video) I'm not sure what checking or unchecking "show sub levels" does. A hierarchical tree is all about various levels and sublevels. And I would think that whatever levels and sublevels we see at any given time would be in response to specific choices made as we go along. So what exactly does "show sub levels" do? I don't understand. Second, I'm not sure about when and how showing or hiding levels in the Navigator effects the showing or hiding of levels in the canvas. At 0:34, clicking "fold all" in the Navigator clearly folds the entire outline in the canvas. But at about 1:13 "Unfold all" seems to unfold only the Navigator tree, while the tree in the canvas remains folded. So I'm confused. I'm similarly confused about when showing or hiding levels in the canvas affects the showing or hiding of levels in the Navigator. At about 1:13, folding everything to Level 1 in the canvas similarly folds the outline in the Navigator. But at 1:38, unfolding the outline in the canvas to level 5 leaves everything in the Navigator folded to level 1. This may be a generic problem of my own: As I've said before, in the Navigator I tend to get lost. But again: Apart from the issue at 1:38 (and leaving aside my confusion about the Navigator), everything in the canvas looks right to me.
(In reply to j.a.swami from comment #11) > Everything on the canvas seems as expected, with one exception: > > At 1:38 I don't understand why unfolding everything (in the canvas) to level > 5 also displays the (no-level) text under level 3. I would have thought that > this text would remain undisplayed and all we would see would be the > subheads at all levels up through 5. > The point being made there is to show that this works not only for folded content outline level limiting. The outline content was unfolded and then the limit level was below level 3 then above which showed the unfolded outline content as it was before limiting. > I do have some other questions, though. > > First, in "Options" (at the start of the video) I'm not sure what checking > or unchecking "show sub levels" does. A hierarchical tree is all about > various levels and sublevels. And I would think that whatever levels and > sublevels we see at any given time would be in response to specific choices > made as we go along. So what exactly does "show sub levels" do? I don't > understand. "Include sub level" means sub levels are treated as content of parent levels. So, if the parent is folded then all content including sub level content is hidden. When sub levels are not being included as content, folding parent content only folds content to the start of the next outline heading, be it a sub level heading or a same level heading or a super level heading. From the documentation: Outline Folding: An extra option (Show outline-folding buttons) is available in Tools > Options > LibreOffice Writer > View (Figure 5). When this option is selected, a button with an arrow is visible near any selected heading in your document. Click on it to fold all text from the current heading to the next heading. If Include sub levels is also selected, clicking on a heading folds all text from that heading to the next same-level heading with all its subheadings. > > Second, I'm not sure about when and how showing or hiding levels in the > Navigator effects the showing or hiding of levels in the canvas. At 0:34, > clicking "fold all" in the Navigator clearly folds the entire outline in the > canvas. But at about 1:13 "Unfold all" seems to unfold only the Navigator > tree, while the tree in the canvas remains folded. So I'm confused. > That was "Expand All", which expands all levels in the Navigator tree. Outline folding options are located under the "Outline Folding" submenu. Showing and hiding of levels in the Navigator does not affect the levels shown/hid on the canvas. The Navigator simply displays the available headings that are in the document. Folded content headings are not shown because they are not visible on the canvas. Perhaps it is better for headings that are not visible to be greyed out in the Navigator, but that is for a different discussion... > I'm similarly confused about when showing or hiding levels in the canvas > affects the showing or hiding of levels in the Navigator. At about 1:13, > folding everything to Level 1 in the canvas similarly folds the outline in > the Navigator. But at 1:38, unfolding the outline in the canvas to level 5 > leaves everything in the Navigator folded to level 1. > When there are only Level 1 Outlines shown in the canvas then the Navigator only displays these because all other outline levels are hidden. This gets back to graying out headings that are not visible. The Navigator tracks content at the cursor position. When showing outline content to level 5, the cursor position does not change, so the highlighted heading in the Navigator does not change. In default outline tracking mode when the cursor is moved, the heading under that cursor is highlighted in the Navigator, which will expand the tree as needed. > But again: Apart from the issue at 1:38 (and leaving aside my confusion > about the Navigator), everything in the canvas looks right to me. Ok, I'll look the patch over again then put it in the master build so you can give more first hand feedback.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5f72a041c0160e4067ca931a9cec711b84b558f4 tdf#142446 Show outline content up to a given outline level 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.
(In reply to Commit Notification from comment #13) > Jim Raykowski committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 5f72a041c0160e4067ca931a9cec711b84b558f4 > > tdf#142446 Show outline content up to a given outline level > > 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. As soon as I click "show outline-content to level" in the context menu, Writer crashes. Ubuntu 22.10. LibreOfficeDev-7.5.0.0.alpha0_2022-10-30-x86_64. AppImage and manual install behave the same way.
(In reply to j.a.swami from comment #14) > As soon as I click "show outline-content to level" in the context menu, > Writer crashes. > > Ubuntu 22.10. LibreOfficeDev-7.5.0.0.alpha0_2022-10-30-x86_64. AppImage and > manual install behave the same way. Thanks for the heads up. The crash happens because I missed adding some file changes to the commit that I had made locally that let the build system know about the dialog. Fix patch on the way.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f8bed5288656575e6f23923bfbd648bfd00c39a6 tdf#142446 follow up: Fix missing ui file crash and a11y ui errors 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.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/be2cd4bcc4e55b9fe6e5fcd6276511d37f3f8e4c tdf#142446 Improve show outline content to level 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.
Version of 2022-11-13 still crashes for me the same way.
(In reply to j.a.swami from comment #18) > Version of 2022-11-13 still crashes for me the same way. I don't get the crash with current Linux and Windows daily builds 2022-11-13. 'Show Outline Content to Level' dialog opens as expected. Perhaps an old daily master build is still installed and it is being run? I use this link to get daily builds for testing: https://dev-builds.libreoffice.org/daily/master/
Got it. Thank you. No longer crashes. 1. In general, looks very good. The "show content to level" command is easy to understand and use. 2. When I issue a command that content should be expanded to more levels, the system sometimes responds a bit slowly. The lag is long enough to create uncertainty as to whether the command has been recognized or not. 3. It seems that specifying a content level greater than 3 has an inconsistent effect. Sometimes specifying "4" shows me level 4, sometimes not. 4. When content is collapsed to a certain level, I would have expected to see the "no-level" content beneath that level collapsed, consistently. Instead, it seems, such content is always shown, unless already collapsed manually with "toggle outline folding." This seems to me a less-desirable approach. Imagine, for example, that I have a several-page hieararchical document, with some of the "no-level content" extending for several paragraphs (or even pages). Using "Show outline content to level" may or may not show me the actual bare-bones outline, depending on what I've previously done. If I have previously collapsed some NL content but not all, expanding or contracting the outline will show me that NL content accordingly, in a manner that would seem to me inconsistent. That is, it would be consistent with my previous actions but inconsistent with what I'm now trying to do, namely view the whole outline at a certain level. 5. All in all, great to see things coming along.
(In reply to Jim Raykowski from comment #12) > (In reply to j.a.swami from comment #11) > > > I do have some other questions, though. > > > > First, in "Options" (at the start of the video) I'm not sure what checking > > or unchecking "show sub levels" does. A hierarchical tree is all about > > various levels and sublevels. And I would think that whatever levels and > > sublevels we see at any given time would be in response to specific choices > > made as we go along. So what exactly does "show sub levels" do? I don't > > understand. > "Include sub level" means sub levels are treated as content of parent > levels. So, if the parent is folded then all content including sub level > content is hidden. When sub levels are not being included as content, > folding parent content only folds content to the start of the next outline > heading, be it a sub level heading or a same level heading or a super level > heading. > > From the documentation: > > Outline Folding: An extra option (Show outline-folding buttons) is available > in Tools > Options > LibreOffice Writer > View (Figure 5). When this option > is selected, a button with an arrow is visible near any selected heading in > your document. Click on it to fold all text from the current heading to the > next heading. If Include sub levels is also selected, clicking on a heading > folds all text from that heading to the next same-level heading with all its > subheadings. > > > > > Second, I'm not sure about when and how showing or hiding levels in the > > Navigator effects the showing or hiding of levels in the canvas. At 0:34, > > clicking "fold all" in the Navigator clearly folds the entire outline in the > > canvas. But at about 1:13 "Unfold all" seems to unfold only the Navigator > > tree, while the tree in the canvas remains folded. So I'm confused. > > > That was "Expand All", which expands all levels in the Navigator tree. > Outline folding options are located under the "Outline Folding" submenu. > Showing and hiding of levels in the Navigator does not affect the levels > shown/hid on the canvas. The Navigator simply displays the available > headings that are in the document. Folded content headings are not shown > because they are not visible on the canvas. Perhaps it is better for > headings that are not visible to be greyed out in the Navigator, but that > is for a different discussion... > > > I'm similarly confused about when showing or hiding levels in the canvas > > affects the showing or hiding of levels in the Navigator. At about 1:13, > > folding everything to Level 1 in the canvas similarly folds the outline in > > the Navigator. But at 1:38, unfolding the outline in the canvas to level 5 > > leaves everything in the Navigator folded to level 1. > > > When there are only Level 1 Outlines shown in the canvas then the Navigator > only displays these because all other outline levels are hidden. This gets > back to graying out headings that are not visible. The Navigator tracks > content at the cursor position. When showing outline content to level 5, the > cursor position does not change, so the highlighted heading in the Navigator > does not change. In default outline tracking mode when the cursor is moved, > the heading under that cursor is highlighted in the Navigator, which will > expand the tree as needed. I now see what "include sub levels" does. It's not simple and obvious, though, and I'm not sure what would be the use case. Having the sub levels included is what I would intuitively expect. Perhaps if being able to choose whether or not to include sub levels does have a common use case, the box to tick should say "do *not* include sub levels" and should function accordingly. Again, though, what this choice is about is not at once obvious. So perhaps further thought here is needed. I won't comment here on the canvas / navigator relationship for folded outlines. Maybe later (although, again, I'm rather a Navigator rookie).
(In reply to j.a.swami from comment #20) > 2. When I issue a command that content should be expanded to more levels, > the system sometimes responds a bit slowly. The lag is long enough to create > uncertainty as to whether the command has been recognized or not. Yes, for large files there can be significant delay when a large amount of layout frames need to be remade. Are you testing with a full debug build or perhaps a container version? These will have slower layout. > 3. It seems that specifying a content level greater than 3 has an > inconsistent effect. Sometimes specifying "4" shows me level 4, sometimes > not. I haven't been able to repro this. Could you supply the steps to repro and attach a test file that this happens? > 4. When content is collapsed to a certain level, I would have expected to > see the "no-level" content beneath that level collapsed, consistently. > Instead, it seems, such content is always shown, unless already collapsed > manually with "toggle outline folding." This seems to me a less-desirable > approach. > > Imagine, for example, that I have a several-page hieararchical document, > with some of the "no-level content" extending for several paragraphs (or > even pages). Using "Show outline content to level" may or may not show me > the actual bare-bones outline, depending on what I've previously done. > > If I have previously collapsed some NL content but not all, expanding or > contracting the outline will show me that NL content accordingly, in a > manner that would seem to me inconsistent. That is, it would be consistent > with my previous actions but inconsistent with what I'm now trying to do, > namely view the whole outline at a certain level. But doing this seems like it would make the feature just an on canvas copy of what the Navigator Headings already does, which is, shows the actual bare-bones outline.
(In reply to Jim Raykowski from comment #22) My apologies for being slow to respond. > (In reply to j.a.swami from comment #20) > > 2. When I issue a command that content should be expanded to more levels, > > the system sometimes responds a bit slowly. The lag is long enough to create > > uncertainty as to whether the command has been recognized or not. > Yes, for large files there can be significant delay when a large amount of > layout frames need to be remade. Are you testing with a full debug build or > perhaps a container version? These will have slower layout. I'm testing with an appimage. The document I tested with is only a page or so, and text only. > > > 3. It seems that specifying a content level greater than 3 has an > > inconsistent effect. Sometimes specifying "4" shows me level 4, sometimes > > not. > I haven't been able to repro this. Could you supply the steps to repro and > attach a test file that this happens? I've been otherwise occupied, so I haven't tested further. Will try. > > > 4. When content is collapsed to a certain level, I would have expected to > > see the "no-level" content beneath that level collapsed, consistently. > > Instead, it seems, such content is always shown, unless already collapsed > > manually with "toggle outline folding." This seems to me a less-desirable > > approach. > > > > Imagine, for example, that I have a several-page hieararchical document, > > with some of the "no-level content" extending for several paragraphs (or > > even pages). Using "Show outline content to level" may or may not show me > > the actual bare-bones outline, depending on what I've previously done. > > > > If I have previously collapsed some NL content but not all, expanding or > > contracting the outline will show me that NL content accordingly, in a > > manner that would seem to me inconsistent. That is, it would be consistent > > with my previous actions but inconsistent with what I'm now trying to do, > > namely view the whole outline at a certain level. > But doing this seems like it would make the feature just an on canvas copy > of what the Navigator Headings already does, which is, shows the actual > bare-bones outline. You're right, of course. But there are those of us who hardly use the Navigator. Either we're not used to it, or we find it confusing, or we just prefer to work directly on the canvas and not open up another panel. On the canvas we use "Show outline content to level. . ." So that's where we want to continue working -- on the canvas itself. On the canvas we interact differently with a document than we do with Navigator Headings. As we fold and unfold things, we see and revise text as we go along, and so on. And we'd like to have Outline Folding work in a way consistent with what we'd naturally expect. Even if folding "non-level" text were to mean we'd be duplicating something one could do in Navigator Headers, that seems fine with me. As long as we're not multiplying extravagantly, we can have two different ways for a user to achieve something, according to his own preferred way of working. In sum: I suggest we're best off having Folding Outlines work in a completely self-sufficient way, independent of what the Navigator may offer. Thank you.
I came here hoping that I was simply missing this feature in writer, but I find that there's a long history of others needing this functionality too and I'm unclear if it will be included in a planned release or if it is documented and may or may not be added. I agree with j.a.swami, as a user who doesn't use navigator at all, my primary use for collapsing headers is to navigate very long documents, especially those with multiple similar sections (ie 2 high level topics with both having legal/budget/actions/etc as sub-headings). Scrolling in that case is a nightmare, but I don't want to loose the screen real-estate by using navigator since most of what I'm doing is reading and typing. I was, however, surprised at the idea that hidden text would not be included in searches or printed. I think of 'folding' or 'collapsing' as a "view" rather than a functional change. The function is related to formatting (H1, H2, etc), but not printing or search because the text is still there, just out of my current view. If I'm alone in that expectation, perhaps a reminder to the user when printing if you find others have different expectations? I don't see a downside to including all text in search - if the user wants a word count or formatting or search applied to only some of the text, highlighting it and then searching makes more sense to me. If my collapsed/hidden text was not visible and wasn't coming up in search results I would go looking for an existing bug report. If you'd like another example of this feature in action, I also use workflowy because of similar functionality. However, I use that primarily for to-do lists. However, it's a nice example of implemented folding/collapsing functionality. I don't work for or have any affiliation with them, and I don't think I even have a paid account, use any of the new features, or have the app, so this isn't a shill comment, but simply a non-Redmond example of the functionality being discussed. https://workflowy.com/features/ As an N of 1, I wouldn't plan on using 'collapse until level X' functionality at all (other than collapse or expand all). The way I use that feature is to examine and edit sections of the document without tons of scrolling as a user who doesn't use navigator. My interaction is on a heading-by-heading basis by clicking the + or - . I'm not sure that matters, but thought I'd throw that out there as the functionality to collapse and un- collapse by interacting with the headers/not navigator is my highest priority feature request.