Description: I have a document with many Paragraph Styles. All of them are shown in the list 'Applied Styles'. I want to hide a subset of them. However, for each of them, the only options actually available are 'New' and 'Modify'; some can also be deleted. The option 'Hide' is greyed out for all of them. Steps to Reproduce: 1. Hit CTRL-F5. 2. At the bottom, choose 'Applied Styles: 3. Right-click on one of them. Actual Results: The option 'Hide' is listed, but greyed out. Expected Results: The option should be available, since it is useful. Reproducible: Always User Profile Reset: No Additional Info: My LO version is actually 7.1.2.2; however, this is not listed among the Versions above.
I bibisected the change with linux-64-7.0 to https://git.libreoffice.org/core/commit/1906f3f2f7c39ea9a3e04f1081dbfc24a1de3212 tdf#128557 Show disabled menu items in style lists context menu I won't call this a regression, but hopefully Jim can weigh in on this. I only see the greyed out context menu items (not only in the Applied Styles view) with GTK3. Not with kf5, gen or Windows.
I think it has always been that the 'Hide' option is not shown when showing the list of 'Applied Styles'. I noticed 'Show' appears in the context menu for hidden styles when they are in the list of 'Applied Styles' and that the context menu in the 'All Styles' list for applied styles does not show the 'Hide' option.
(In reply to Jim Raykowski from comment #2) > I think it has always been that the 'Hide' option is not shown when showing > the list of 'Applied Styles'. I noticed 'Show' appears in the context menu > for hidden styles when they are in the list of 'Applied Styles' and that the > context menu in the 'All Styles' list for applied styles does not show the > 'Hide' option. The thing that changed with your commit is that with GTK3, we see greyed out Hide, Show, Delete in the context menu (not only with Applied styles). The other backends behave as in the past.
Other than gtk3 backends remove menu items with sensitivity set false. For these backends this is made so here: https://opengrok.libreoffice.org/xref/core/vcl/source/window/menu.cxx?r=cf730619#2903 Removing this will result in greying out instead of removal of menu items. If I understand correctly this report is about not being able to use the 'Hide' menu item on styles while in the 'Applied Styles' list. I think we should ask the UX team for help.
(In reply to Jim Raykowski from comment #4) > Other than gtk3 backends remove menu items with sensitivity set false. > > For these backends this is made so here: > https://opengrok.libreoffice.org/xref/core/vcl/source/window/menu. > cxx?r=cf730619#2903 > > Removing this will result in greying out instead of removal of menu items. > > If I understand correctly this report is about not being able to use the > 'Hide' menu item on styles while in the 'Applied Styles' list. > > I think we should ask the UX team for help. Ok, thanks for clarifying. So this is not about the Applied Styles list per se. This is about if we want to allow hiding styles that have been applied to the document. The current behaviour is to not allow this.
Allow me to clarify why I think this is needed: The list of styles applied in the document may be longer than the screen height, which forces me to scroll. I can avoid this, and get quicker access to a style to be applied, if the list is shorter. The list may contain a subset of styles which, although they have been applied to items in a certain section of the document, are not going to be applied to further items. These are the ones that may as well be hidden.
Another use case might be to prevent accidental changes to a style. When "Hidden" is not an extra filter category we need to deal with the fact that "Applied" does not show all applied styles. Workaround (or rather the supposed workflow) is to move some of your "Custom" styles into a category like "Special" (available in the Organizer tab). And perhaps make this list expandable. This ticket is kinda duplicate of bug 107479 and has a see-also in bug 119919 talking about hierarchical hiding. Mike, what's your take?
I can see no way of _moving_ a style from one category into another. So how exactly is this workaround to work?
(In reply to Christian Lehmann from comment #8) > I can see no way of _moving_ a style from one category into another. So how > exactly is this workaround to work? "Modify" the style and find a "Category" dropdown under "Organizer".
That does not seem to solve it: I modify the style and, under organizer, choose to store it under 'Special styles'. I now have a copy of the style in this category. Now I delete it from Custom styles. I get a warning that this will delete all occurrences of the style in the file; which is not what I want. I delete it nevertheless. The warning comes true. Moreover, surprisingly, the style is now deleted not only from Custom Styles, but also from Special Styles. It seems that this is not only not a workaround for the initial problem, but in itself does not really work as expected.
(In reply to Christian Lehmann from comment #10) > That does not seem to solve it: > > I modify the style and, under organizer, choose to store it under 'Special > styles'. I now have a copy of the style in this category. Now I delete it > from Custom styles. I get a warning that this will delete all occurrences of > the style in the file; which is not what I want. > > I delete it nevertheless. The warning comes true. Moreover, surprisingly, > the style is now deleted not only from Custom Styles, but also from Special > Styles. > > It seems that this is not only not a workaround for the initial problem, but > in itself does not really work as expected. You got it the wrong way around. You can think of the category as a property of the style. Thus, the delete action concerns the style itself. You do not "uncategorise" it as you thought. The lists in the Styles sidebar are merely views, like information filters. I hope it helps to conceptualise.
Thanks for the explanation. However, the initial problem was to get the style in question out of the list of Applied Styles. If the action that Heiko recommends only copies the style into an additional category, but cannot remove it from its source category, it does not seem to contribute anything to the initial problem.
(In reply to Heiko Tietze from comment #7) > Another use case might be to prevent accidental changes to a style. Hide *applied* styles in the list to prevent editing them is absolutely useless. You always can select a text with the style and right-click it to edit its styles. "Accidental" editing when you need to open a window, right-click there, then do something in dialog and confirm is hardly "accidental". IMO purely invented scenario. I suppose that this is just another case where having N recent used styles grouped at the top of the list would solve the problem.
Once you have the feature 'Hide styles', what speaks against making it available to the user in the case at hand, i.e. for applied styles?
(In reply to Christian Lehmann from comment #14) Nothing. You could look closely to the phrase and notice that it was citing a specific text that it argued against. I was arguing that trying to invent additional use cases is not useful, but I never questioned your original request (while I still believe that if that other option was implemented, your request would likely not appear).
Mike, please don't feel attacked. My question was meant as an observation on the conclusion drawn in Comment 5 from the preceding discussion. The general problem with moving recently-used things to the top of the list (I say "things", because the problem is the same for "Recent files, Recently-run programs" and such like) is that if you have the list in order of recency, any systematic order, like alphabetic order, thereby disappears. In the present case, the user who does not remember which style he used in the 6th most recent place would have to scan the list in order to pin down the style he wants.
(In reply to Christian Lehmann from comment #16) > The general problem with moving recently-used things to the top of the list > (I say "things", because the problem is the same for "Recent files, > Recently-run programs" and such like) is that if you have the list in order > of recency, any systematic order, like alphabetic order, thereby disappears. No, if the "N Recently User Things" are separated from the following *full* list in systematic order (having the same items that appear in the "recent" list, duplicated to also appear on proper places).
Okay, if this is more user-friendly than allowing the user to hide what he does not want to see (or has some other advantage), go ahead.
(In reply to Christian Lehmann from comment #10) > That does not seem to solve it... No, it's a workaround. Custom Styles is a subset of Special Styles, or vice versa. We should focus on this and enhance the filtering rather than hiding used styles. There are several tickets, such as bug 69551 or bug 90646.
No further input, let's follow the user-defined style category path.