Description: Upon installing Writer in LO 6.1, I found a huge list of previously hidden paragraph styles styles appearing in the top level of the Hierarchical View in the sidebar. Upon further inspection, it looks like styles that I directly marked as hidden are still hidden, but their children have become un-hiddden, dumped at the top level since there is no where else for them to go. The same appears to be true for Character Styles. Calc appears to do the same thing with Cell Styles, except that the child styles appear under "Default", since Calc does not allow styles that are not descendants of Default. The previous behavior (v6.0 and earlier), where children of a hidden style are also hidden in the Hierarchical View, should be restored. Steps to Reproduce: 1. Make at least 2 levels of nested styles past the default. 2. Hide the parent style. Actual Results: Child style appears at the top level. Expected Results: Child style is hidden with the parent. Reproducible: Always User Profile Reset: No Additional Info:
I don't like both ways--hiding all child styles (in earlier LibO versions) and moving up the child styles in the hierarchical view (in current LibO version). Both are not logical. (Formerly: Where is my Style xyz? Now: Why do I have so many new styles in the first level of my hierarchical view?) But I think the new way is more understandable by users. Only styles that are hidden manually should be hidden. Maybe a user wants to hide the mother style of a child style but not the child style itself. This concept is a WORKSFORME. My preference is adding new context menu commands in the styles sidebar named 'Hide incl. inherited styles' and 'Show incl. inherited styles'. With that all child styles should be hidden/shown as well. That will save time for the user and avoids that all styles must be hidden/shown manually and it gives something like a 'learning effect' ("Aha, I also can hide the child styles of this style."). Adding needsUXEval.
The hide/show functionality does not work at all. Tried with Test (None), 1 (Test), 2 (1) and hid 1 which makes 2 disappear. Some other test with default styles were as described but cannot rerun for some reason. Besides I agree with Thomas that hiding children is awkward. OTOH it also is weird when your tree suddenly switches from Foo > Bar > Qux to Bar > Qux after hiding Foo. So either we keep the hidden styles alive in the tree and just grey them out or select the first children, in the example Bar to keep the position. "Hide tree" (or the like) as additional command is also an option. Some styles must not be hidden, Default for example - not only when used. I can do so for Text Body but this item is still shown then. Maybe my test program is not up tp date. Version: 6.0.4.5 Build ID: 6840e4519a6ce8bcc1328eb2d87b5c46c6df1038 CPU threads: 4; OS: Mac OS X 10.13.6; UI render: default; Locale: de-DE (de_DE.UTF-8); Calc: group
@Heiko I hadn't tested a style tree not inheriting from Default, but I tried it just now and it works the same either way. Are you using version 6.1? I see 6.0.4.5 in your comment. Also, I'm having trouble understanding the objection to hiding children of hidden styles in the hierarchical view. What else would someone expect to happen when you right click an entry in a tree and select "hide", except for the entire subtree to be hidden? @Both Perhaps the problem is this. I *always* use the hierarchical view. But let's imagine someone who normally use one of the other views, and doesn't have a grasp of which styles are children of which. (This doesn't make much sense to me, since it's rather critical to using nested styles, period.) If such a person hides a parent style from one of those views, and later switches to the hierarchical view, they might be confused as to where the children went. @Heiko (again) I'm not sure if the second paragraph, but it sounds like you're suggesting flattening the tree such that the children of a hidden style appear in the position the level the parent would have been. This sounds even more perilous to me, because it suggests a false relationship between the styles. Now, I'd like to give a suggestion of my own. Include a checkbox for *all* views, which hides/shows hidden styles as appropriate to the view. For hierarchical, this would mean hiding children of hidden styles, for all others, it would mean hiding only the hidden styles themselves. All unhidden entries could be gray, italic, or whatever deemed appropriate. Then, the separate Hidden Style view might not even be necessary. I think this would accomplish essentially the same thing as Thomas's suggestion, while being simpler and more uniform. If you're searching for an entry that isn't there, just click the checkbox and all will be revealed.
(In reply to Heiko Tietze from comment #2) > Some styles must not be hidden, Default for example - not only when used. I > can do so for Text Body but this item is still shown then. Maybe my test > program is not up tp date. See Bug 107479 - Style "Text Body" can't be hidden.
(In reply to Kenneth Hanson from comment #3) > @Heiko I hadn't tested a style tree not inheriting from Default, but I tried > it just now and it works the same either way. Are you using version 6.1? I > see 6.0.4.5 in your comment. > Also, I'm having trouble understanding the objection to hiding children of > hidden styles in the hierarchical view. What else would someone expect to > happen when you right click an entry in a tree and select "hide", except for > the entire subtree to be hidden? As said, when you create MyStyles with lets say A4 below and A4_Letter, A4_Document as children and delete A4 all below should be gone too. But if the tree structure is not that hierarchical with something like Public_Communication > Letter, Declaration, Foo it makes sense to keep the items below. And as mentioned by Thomas it's safer to keep the children than removing them if we discuss what use case is to prefer. > @Heiko (again) I'm not sure if the second paragraph, but it sounds like > you're suggesting flattening the tree such that the children of a hidden > style appear in the position the level the parent would have been. This > sounds even more perilous to me, because it suggests a false relationship > between the styles. Good point. There is no solution that keeps the relation of children consistent if the parent is hidden. > Now, I'd like to give a suggestion of my own. Include a checkbox for *all* > views, which hides/shows hidden styles as appropriate to the view. For > hierarchical, this would mean hiding children of hidden styles, for all > others, it would mean hiding only the hidden styles themselves. All unhidden > entries could be gray, italic, or whatever deemed appropriate. Then, the > separate Hidden Style view might not even be necessary. Sounds reasonable, we have other tickets requesting changes like this (Thomas will find the right bug). Actually "Hidden Styles" as an own category makes no sense.
(In reply to Heiko Tietze from comment #5) Good point about deletion. It would definitely not be desirable to delete the entire subtree, at least, not by default. In the case of hiding, likewise, we don't want to actually hide the entire subtree, in the sense of giving each style the attribute "hidden". Rather, the question is what to do about the children when the parent is deleted or hidden. In the case of deletion, the children should move up to the parent's position in the tree. At least, that seems to be what LibreOffice does. In the case of hiding, we have several possibilities under discussion: 1. Hide the children as well (as in v6.0) 2. Show them at root level (as in v6.1) 3. Collapse the tree, showing the children at the level of the hidden parent (or grandparent, etc.) I maintain that (2) is unacceptable, and (3) is questionable. Furthermore, we have two ideas for configuration: 4. UI switch for whether descendants of hidden styles are shown or hidden (Thomas's proposal) 5. UI switch for whether hidden styles and, if applicable, their descendants, are shown or hidden (my proposal) I can also imagine a variation of (5), where the UI switch affects only hidden styles themselves even in the hierarchical view, while children of hidden styles are shown at the parent level, as in (3). Call this option (6). I think that (5) is the best solution we have so far.
Hidden nested styles are only a problem in the hierarchical view. What if instead of the hidden (parent) style we show only the maybe italic/grey-colored word '(hidden)' at the tree structure place where the hidden style normally appears. The hierarchical view is not designed for that to hide a style in the middle of beginning of a tree. Only the last child of a tree can also be really hidden. All other views are not affected by such change.
(In reply to Kenneth Hanson from comment #3) > Now, I'd like to give a suggestion of my own. Include a checkbox for *all* > views, which hides/shows hidden styles as appropriate to the view. For > hierarchical, this would mean hiding children of hidden styles, for all > others, it would mean hiding only the hidden styles themselves. All unhidden > entries could be gray, italic, or whatever deemed appropriate. Then, the > separate Hidden Style view might not even be necessary. As there is a filter 'Hidden styles' I don't want to add a new checkbox that also works with hidden styles. That's confusing. Keep it simple. As I already said in comment 7, I would scrap the full hiding feature in the 'Hierarchical' filter view and the hidden styles should be shown maybe in square bracket, italic and grey colored (but italic and colorization can come into conflict with user color settings for that styles, hm). And these styles shouldn't be editable. Only the 'Show' item should be visible in the context menu of hidden styles. (If they were fully hidden the user can't edit them anyway.) - Reason: Hiding 'bar' in foo1 > bar > foo2 to only show foo1 > foo2 in the hierarchical view doesn't reflect the dependencies and therefore this is false and misleading. Additional note to my suggestion in comment 1, point 4 in Kenneth's comment 6 (new context menu command to also hide also child styles): After thinking about it I consider it problematic when doing that in all non-hierarchical filters as the user doesn't see which styles will be affected.
(In reply to Thomas Lendo from comment #8) > As I already said in comment 7, I would scrap the full hiding feature in the > 'Hierarchical' filter view and the hidden styles should be shown maybe in > square bracket, italic and grey colored (but italic and colorization can > come into conflict with user color settings for that styles, hm). And these > styles shouldn't be editable. Only the 'Show' item should be visible in the > ... I like that proposal. > Additional note to my suggestion in comment 1, point 4 in Kenneth's comment > 6 (new context menu command to also hide also child styles): After thinking > about it I consider it problematic when doing that in all non-hierarchical > filters as the user doesn't see which styles will be affected. Makes sense.
So the design team recommends to not hide the hidden styles in tree view mode but show as disabled/greyed-out. Ideas to remove the hide feature completely were discussed and we better keep it as some users may take advantage of it at other type of views such as All Styles. Removing UX, set as enhancement. Could be an easyhack.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f2a2ca8a9d4bf0314b2012cc1d066c65044bd5e0 Resolves tdf#119919 - Show hidden children in Stylist when in tree mode It will be available in 7.6.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.
Hidden styles are now still shown when in hierarchical mode but in a disabled / grayed out font color.