Problem description: When paragraph style is inherited from some parent it ingerit most of properties except those were manually changed. Those properties are listed in Contain section on Organizer tab. But if there are lot of changed properties searching of them is not simple and convenient. It would be perfect to see status of each style property inplace besides contain section. Moreover there's no way to reset any property to be inherited. Changing of property to parent's value does't make it inherited. (The only way in this case is to workaround with creating new style, selecting all oldstyled paragraphs and set to them the new one. But it have its own troubles). Steps to reproduce: 1. Change one property in inherited paragraph style (it would appear on organizer tab) 2. Change the property back to parent value Current behavior: The property is still listed on organizer tab and does not inherit. Expected behavior: The propery that is changed have button or any different way to reset proprty status to be inherited.
Component is 'ux-advise', so Status -> NEW
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
Don't understand your problem. You modify the style, e.g. per right click in the styles & formatting sidebar, and it is not clear what happens? The preview is not that bad, IMHO. Or do you make a direct formatting via toolbar > font size, for instance, and wonder what happen to the style. And last but not least you could talk about paragraph style vs. character style that is not easily to discriminate from each other when applied to the whole paragraph.
@Heiko: This report is about managing the content of hierarchical styles in the Style&Formatting dialog. You can set a property back to 'inherit': In the style properties go to the tab, which contains the property. Then click on button "Standard". Go back to 'Organizer' tab and look what has been removed. Unfortunately there is no way to set a single property of the tab page back to 'inherit'. And sometimes the property is removed but still shown in 'Organizer' tab. There are similar requests in bug 89826, bug 77325 and bug 88921. The second is about making the inheritance visible in the tab pages. I can think of making the item "italic" or for field entries adding an indicator before or after the content, e.g. '(i) 12pt' instead of simple '12 pt'. No idea how to do it for other kind of controls. The problem is very old see https://bz.apache.org/ooo/show_bug.cgi?id=3148 I support both requests.
(In reply to Regina Henschel from comment #4) > @Heiko: This report is about managing the content of hierarchical styles in > the Style&Formatting dialog. Was afraid of this answer ;-). So what we need is an indicator at the various properties which one has been overridden. For example, "Caption" has the children "Drawing" and when font style is set bold there instead of italic from the parent it should get an identification. Known solutions are a small icon next to the label, simpler is to add a * to the label or to modify it's appearance, e.g. text in blue. But the latter could get into conflict with the theme.
We should add a section above 'Contains' called 'Inherited' and then list the name of the parent style followed by its attributes that arent being overwritten by the child style. Example design below for Heading 1 Inherited Heading: Western text: Liberation Sans, From bottom 0.08 inch + Keep with next paragraph Contains Western Text: 130% + bold + Numbering(Outline) + 1 + Indent left 0.0 inch, Indent right 0.0 inch + From top 0.17 inch, From bottom 0.08 inch Note: 14pt isnt displayed in 'Heading' as it is being overwritten by the 130% in 'Heading 1'.
(In reply to Regina Henschel from comment #4) > The second is about making the inheritance visible in the tab pages. I can > think of making the item "italic" or for field entries adding an indicator > before or after the content, e.g. '(i) 12pt' instead of simple '12 pt'. No > idea how to do it for other kind of controls. I also think, if a font and its size is inherited from the Basic Fonts in the options dialogue [LibreOffice Writer > Basic Fonts (Western|Asian|CTL)], that this should be indicated somehow, e.g. '(o) Liberation Serif' or '(o) 12pt'.
(In reply to Heiko Tietze from comment #5) > (In reply to Regina Henschel from comment #4) > > @Heiko: This report is about managing the content of hierarchical styles in > > the Style&Formatting dialog. > > Was afraid of this answer ;-). > > So what we need is an indicator at the various properties which one has been > overridden. For example, "Caption" has the children "Drawing" and when font > style is set bold there instead of italic from the parent it should get an > identification. Known solutions are a small icon next to the label, simpler > is to add a * to the label or to modify it's appearance, e.g. text in blue. > But the latter could get into conflict with the theme. Or a (kind of) (colored) border around the dialog items which are inherited. Area would be slightly problematic area. However it would work. Not sure if this is a11y proof.. Ideally combined with a tooltip kind of thing to show where the style is coming from.
This has been implemented during GSoC20 by Shivam Kumar Singh [1], remaining tickets are handled in bug 134554. [1] https://shivam-51.github.io/
It can NOT be any kind of WORKSFORME - just because somewhere there is now a power tool, usable only by power users. This is a really needed missing feature - and it is independent of the Styles Inspector. The style and direct properties dialogs must have indication about what was defined here, and what was not.
*** Bug 137439 has been marked as a duplicate of this bug. ***
I support Mike's objection in comment 10. Neither single settings can set back to its inherited value nor inherited values are visible in the Styles dialog.
Small inquiry. This bug and bug 89826 are about the same topic? And works for me because of "Display" taken literally here? Agreeing with comment 10 of course, but could also be bug 89826
Caolán: this bug (a major usability pain actually) depends on abilities of used controls; could you please advise? This (and related bug 89826) might have many possible fixes, e.g.: - controls showing default values having blue border (accessibility problem?) - having bold labels (same) - having labels include some indicator text - dedicated additional labels *after* (to the right of (in LTR case)) controls - having no value at all (but what about controls like borders/color picker, which are not edit controls? Create special "blank" states for them?) - a variation of the latter, when the controls do have values, but in grey color - a small "lock" button next to *each* control which pressed state means "use inherited" ... They all seem to have multiple problems (accessibility; cluttering, etc) - but the main problem is implementability. The way to indicate the status of *each single property* in style dialogs (inherited or defined explicitly here in this style), and (to a lesser extent) a way to reset that single property to inherited status, is really needed thing. The problems should be fixed after the fact (e.g., accessibility could be handled by providing appropriate information to screen reader and tooltip; clutter is of less importance, and let design team to re-order controls to fit better after the fact, etc.) I say that resetting single properties is needed "to a lesser extent", because if the controls would indicate their "inherited" status (say, have colored border), then using "Standard" button to reset to inherited would be much more usable. But of course, a combined solution (like a small button) would be welcome by many. Could you please advise what solution is possible/preferred?
Well, I don't really have any good answers wrt any specific solution, digging around similar software doesn't show anything obvious to follow as a model. But from a weld api view we use e.g. "set_message_type" to indicate that an Entry contains an error and not specify how it indicates that error. So I could imagine something similar that leaves it up to each backend to figure out what to do to make that happen in the context of their own capabilities. Maybe adding some "reset" to right context menus avoids the clutter of extra buttons for that functionality, maybe labels are underlined or widget backgrounds set to some appropriate theme color. Maybe something like this feature shouldn't be on all the time, but only if some togglebutton in the button area is depressed. Such a special state would give a little more leeway in that a backend could then position a little "reset" button over the middle of widgets to allow them to be designated reset-back-to-parent. Having a toggle to enable some sort of "overlay" like that would sidestep visual clutter and any need to change any widget layout.
As far as I understand, there are the following problems for the UI here: 1) How are unspecified properties of a style handled? a) How can the user leave the value for a selected property unspecified? b) What does it mean to leave an inherited property unspecified? 2) How can he get an overview that distinguishes between: a) values that he fixed for this style b) values that his style inherits from the parent (that he chose when pressing 'New') c) values that remain unspecified and will be fixed only once a string thus styled is embedded in a given context. Ad 1: Several voices agree that pressing the 'Standard' button is both too sweeping an action and not really intuitive if one just wants to leave one property unspecified. (This doesn't entail, of course, that the button should be removed.) Couldn't the list of values enumerated for each of the properties comprise a value 'none'? (Or alternatively a blank field?) As the user starts defining his style, each properties tab would show, for each property, the value inherited from the chosen parent, and otherwise 'none'. a) The user could set the value of any property to 'none'. For a character style, this would mean that the value is (not inherited from that style's parent, but instead) assigned once a string thus styled is embedded in an actual text. In the tab containing the property in question, this selection of the user's would keep being shown; i.e., Writer would not replace it by the current default value, in order not to mislead the user about what he fixed and what he left open. b) Selecting 'none' as the value of an inherited property does not seem to make sense. More in general, one may wonder what sense it makes for the user to change the value of a property that is inherited from the parent that he himself chose. To the extent that he changes the values of such properties, his new style is not actually a child of the chosen parent. If he really wants that, maybe LO should encourage him to step up the hierarchy in choosing an appropriate parent. (As a side effect, such a constraint would greatly simplify handling of the styles hierarchy.) Ad 2): I think something like comment 6 would solve it for items #a and #b. Nothing needs to be shown about item #c.
(In reply to Christian Lehmann from comment #16) Please don't make this issue confusing. Your comment made at least two unrelated expansions to the specific issue tracked here. 1. You added a *different* (and real) problem that Character styles may have some properties unspecified, and should not in fact display random values instead. As said: although real problem, this should be tracked separately (possibly already filed?). 2. You suggested a totally new feature to allow making any property undefined, *regardless of inherited state of it*. It is totally irrelevant here. It needs an own feature request.
Personally my preference (visually and functionally) would be a *small button* attached to each property's *label*; something like the small "More options" buttons in sidebars, just named "Revert to inherited". They could have tooltips for discoverability; enabled state for indication of "not inherited = defined here" state; and some mnemonic pictogram resembling theme's "undo". This would slightly increase space used for the labels, but would allow to unify this feature - to avoid problems of different resetting methods for e.g. textual properties vs borders or the like... And I suppose that making it always visible is better compared to a toggle, because this functionality is not something "optional" or "advanced".
(In reply to Mike Kaganski from comment #17) > (In reply to Christian Lehmann from comment #16) > > Please don't make this issue confusing. It is by treating a display problem in isolation and proposing ad hoc solutions for it that one confuses things. I was trying to be more circumspect. > Your comment made at least two unrelated expansions to the specific issue > tracked here. > > 1. You added a *different* (and real) problem that Character styles may have > some properties unspecified, and should not in fact display random values > instead. As said: although real problem, this should be tracked separately > (possibly already filed?). Yes of course, in Bug 137439, which you yourself marked as a duplicate of the present bug. Now is it isn't it a duplicate? > 2. You suggested a totally new feature to allow making any property > undefined, *regardless of inherited state of it*. It is totally irrelevant > here. It needs an own feature request. Did I suggest this?
(In reply to Christian Lehmann from comment #19) > > 1. You added a *different* (and real) problem that Character styles may have > > some properties unspecified, and should not in fact display random values > > instead. As said: although real problem, this should be tracked separately > > (possibly already filed?). > Yes of course, in Bug 137439, which you yourself marked as a duplicate of > the present bug. Now is it isn't it a duplicate? In bug 137439, the original problem was "I cannot make some style avoid definition of some property". That was because of this bug primarily. Also it *happened* to operate on a character style not based on a parent which would define that specific property, thus mentioning the other problem. Please re-read my description in that bug: "yes there is problem A, but the *main problem* is problem B". So marking that bug as duplicate of problem B does not make it equal to problem A. > > > 2. You suggested a totally new feature to allow making any property > > undefined, *regardless of inherited state of it*. It is totally irrelevant > > here. It needs an own feature request. > Did I suggest this? (In reply to Christian Lehmann from comment #16) > a) The user could set the value of any property to 'none'.
Created attachment 166403 [details] Mockup with small buttons at labels This mockup shows the idea from comment 18. There are buttons at labels for individual controls (Left/Right/Top/Bottom...); or at groups of controls where they define a single property (Line Arrangement, Shadow Style). Grey mean "no resetting to inherited possible" == "these are already inherited values". The tooltip allows to see what this button does. The tooltip could of course change to "This value is inherited" for grey buttons. As shown, this problem (tracked in this bug) is orthogonal to the problem what to display for "not defined in parents" values, which, as mentioned in comment 17, must be a separate issue.
Thanks for your Mockup, but just for clarifcation: It shows page style dialog, where inherited styles are not possible (at least at the moment). I assume, the mockup is only for paragraph style dialog and character style dialog. Correct?
(In reply to Dieter from comment #22) Absolutely. Another possible inaccuracy is that I didn't care to check which attributes there actually relate to a single inheritable property, and which are separate (so maybe e.g. Left/Right/... should had not have their separate buttons, but one common) ... I assumed that the idea is still shown.
Hi Mike, (In reply to Mike Kaganski from comment #21) > Created attachment 166403 [details] > Mockup with small buttons at labels Thanks :) Has it been considered to have one 'revert to inherited' button per tab page?
I want to remind everyone that in addition to the more involved changes to the UI, Yousuf suggested: (Yousuf Philips (jay) (retired) from comment #6) > We should add a section above 'Contains' called 'Inherited' and then list > the name of the parent style followed by its attributes that arent being > overwritten by the child style. I believe this should be implemented independently of other changes. IMHO this is both easy to implement, has no drawbacks that I can think of, and will not interfere with changes to the rest of the UI. (In reply to Mike Kaganski from comment #18) > Personally my preference (visually and functionally) would be a *small > button* attached to each property's *label* Looked at the mockup. I support this general approach (of per-item toggles), but currently I feel this makes the dialog feel too cluttered. Possible mitigations/improvements: * Have the per-property control indicate "non-inherited" vs "inherited"status by some other way than grayed-out / non-grayed-out. * The per-property toggles will have lower visibility / attract less attention, e.g. * invisible when not hovering over the main control or the toggle, and/or * black circle-surrounded control over gray dialog background * Per-tab or per-dialog control (e.g. checkbox) of whether the per-property toggles are visible/usable or not. An alternative idea altogether to Mike's mock-up is to have a per-tab/per-dialog toggle which highlights non-inherited properties, or perhaps hides inherited properties. Not sure I'm in favor of this, it's just a thought.
Meanwhile we implemented the Styles Inspector which does exactly this, showing the attribute inheritance. My take, resolve WFM. Regarding Mike's mockup I think it's about the missing capability to remove attributes and reset it individually to the parent. There is another ticket for this specific feature.
(In reply to Heiko Tietze from comment #26) > Meanwhile we implemented the Styles Inspector which does exactly this, > showing the attribute inheritance. It doesn't do what's requested in this bug, which is: When you choose to modify a style and as you modify it, have an indication of the inherited attributes. You could argue its existence weighs against going to great lengths and possibly cluttering the style editing dialog UI in order to achieve this end; but it's certainly doesn't satisfy the same need. > Regarding Mike's mockup I think it's about the missing capability to remove > attributes and reset it individually to the parent. There is another ticket > for this specific feature. But the small per-setting control is usable to, at the time, show the inherited/non-inherited state and be able to reset to "inherit". Anyway, I really don't see how there could be any argument again splitting the "contains" text into an inherited part and an explicitly-set part.
Created attachment 187776 [details] Example from KDE KDE's system settings do have something similar: a dot indicator that shows what option was changed. We should do the same and show those indicator if for altered attributes. Related to bug 155113 the indicator would be visible but off (maybe grayed out or just another icon) if something has changed. And it has of course the states on (visible) and off (hidden).
*** Bug 156180 has been marked as a duplicate of this bug. ***
Unaware of this bug, I mentioned the same issue in the related bug 158784. My suggestion there was to parenthesize inherited values. I’m thinking the notation would be pretty easy to understand and distinguish visually. To reset the value of an inherited property to that of the parent, one could simply clear the field and move focus out of the field (or just apply the change). This would avoid the addition of a new UI element for every field, which might result in too much clutter. Currently, clearing a field and applying the changes doesn’t do anything (i.e., the previous value is just silently restored), so implementing a new behaviour there should be fine. The complementary action of fixing the value of a currently inherited property could be accomplished by entering it again without the brackets or by clicking the up & down arrows so as to briefly adjust the (numeric) value and change it back. Currently, changing a value back and forth (without applying the change) doesn’t dirty the field, but if we had a visual indicator of inheritance status, it would be reasonable to do so. Obviously, all of this only works for text fields (most of which hold numeric values) and not things like checkboxes and dropdowns. But IMO text fields are the ones that would benefit the most from granular control and inheritance indicators. We already have a “Reset to Parent” button. On tabs that consist mostly of checkboxes etc., I’m happy to reset the entire tab and then just recheck what I want. Text fields are much slower to fill in, plus I would imagine that the various numeric values are the most frequently adjusted properties of paragraph styles.
(In reply to bintoro from comment #30) > But IMO text > fields are the ones that would benefit the most from granular control and > inheritance indicators. I disagree. Plus, even if this were true, other fields would still benefit from this. > We already have a “Reset to Parent” button. On tabs > that consist mostly of checkboxes etc., I’m happy to reset the entire tab You may be, but others aren't... :-( Plus, some tabs consist of textual, checkbox and other widgets.
*** Bug 163261 has been marked as a duplicate of this bug. ***