Standard/Set to Parent button appears in three styles dialog (Paragraph, Character, Frame). It should only be active when there are actually values in a tab that can be changed by this button. Relevant values are listed in "Contains". If nothing in Contains is found on the current tab, then the Standard(Set to Parent) button should be greyed out.
Perhaps I'm not familiar enough with function of that buttons. But I understand, that Standard/Reset to parent changes all settings to the settings of th parent style. So I would expect, that button is only greyed out, if there is no parent style. Since a style with no parent has values in "Contains", there's no logic for me, if Standard/Set to parent is active in such a case (what is the expected result)?
(In reply to Dieter from comment #1) > Perhaps I'm not familiar enough with function of that buttons. After some testing, I do understand the funktion now and I support the enhancement request. But current UI makes it very difficult to understand, that standard button is part of the current tab and not part of the whole dialog (as I always thought).
It becomes more clear when the button is placed in the organizer next to the attributes it will remove. Bug 89826 requests removal of individual attributes with the suggestion to have a superscript x on each and clicking removes only this attribute. Adding this just for completeness.
(In reply to Heiko Tietze from comment #3) > It becomes more clear when the button is placed in the organizer next to the > attributes it will remove. I totally agree. It is confusing, if there are several buttons next to each other and one button (Standard) effects the current tab and another (Apply) the whole dialog (Don't know, if Reset-Button effects the current tab or the whole dialog)
(In reply to Dieter from comment #4) > (Don't know, if Reset-Button effects the current tab or the > whole dialog) (applies only to current tab) This information is now available in the tooltip (in current master). (bug 128469)
(In reply to Dieter from comment #1) > ... that button is only greyed out, if there is no parent style. Yes, all styles have parents. And the Default PS is "derived" from hard-coded constants (or what is defined in the template) and can be "Reset to Parent" as well. Happens also for other PS with no parent. So nothing to disable, => WF
(In reply to Heiko Tietze from comment #6) > (In reply to Dieter from comment #1) > > ... that button is only greyed out, if there is no parent style. fwiw -- this is a reply to a comment that starts "Perhaps I'm not familiar enough with function of that buttons" -- and not a reply to the OP, which points out: "If nothing in Contains is found on the current tab, then the Standard(Set to Parent) button should be greyed out." Further explanation: 1. Reset to Parent applies only to the current tab. 2. This button would only be relevant if a value was changed from the parent or hard-coded constant. 3. It would make it easier for a user to recognize that something was changed in a tab if this button was only active when something actually had been changed. > Yes, all styles have parents. And the Default PS is "derived" from > hard-coded constants (or what is defined in the template) and can be "Reset > to Parent" as well. Happens also for other PS with no parent. So nothing to > disable, => WF This is not really relevant to the point of the OP. Of course nothing happens if no changes were made for the tab and the button is clicked. So not a serious problem if not changed. But if the button were greyed out unless there were changes to the tab, then it would be informative to the user -- without forcing the user to switch to the Contains tab, to see if something on the selected tab was listed there.
(In reply to sdc.blanco from comment #7) > But if the button were greyed out unless there were changes to the tab, > then it would be informative to the user... True, but means to check every single attribute. Thanks for the clarification :-)
(In reply to Heiko Tietze from comment #8) > True, but means to check every single attribute. Seeking clarification about meaning of your argument. 1. "True" => you agree that it would be informative for the user? 2. "but..." => it would be too difficult to do, compared to the advantage? => worth doing (if it is not difficult)? 3. Presumably "every single attribute" was meant to imply "too difficult". 4. But does "every single attribute" refer to all attributes for a style or only to the current tab (which is what is actually required). All attributes for a tab (alone) may be more manageable. Also, wouldn't difficulty depend on the internal coding of attributes (e.g., maybe changes are already flagged, so that they will appear in the "Contains" list in the Organizer tab). (fwiw, it would be a nice feature to have. Would make it much easier to know if a tab in a style was modified from a default.).
(In reply to sdc.blanco from comment #9) > 1. "True" => you agree that it would be informative for the user? Yes > 2. "but..." => it would be too difficult to do, compared to the advantage? > => worth doing (if it is not difficult)? You have to compare every single attribute that can be changed with this dialog to know whether or not the button is to enable. It's not difficult but cumbersome and error-prone (any later change needs to be tracked too). The advantage of the disabled button does not outweigh the effort for me. Keep in mind that you want to kind of document the UI rather than blocking input. > 3. Presumably "every single attribute" was meant to imply "too difficult". > 4. But does "every single attribute" refer to all attributes for a style or > only to the current tab (which is what is actually required). In any case, you have to collect all the details. And there are some attributes hidden in extra dialogs. > All attributes for a tab (alone) may be more manageable. If the attributes are tab-dependent you have to collect all plus on which tab it is located. You are welcome to implement, UX-wise it won't interrupt anyone's workflow and is an improvement :-)