1. At present the "Inherit From" control in all Frame Styles is "None". 2. This makes it ambiguous/unclear what happens with the "Standard" Button is used. Suggestion: 1. Add a "default Frame Style" to Sidebar for Frame Styles. (just like Paragraph, Character, Page, which already have Defaults) 2. Have the builtin Frame Styles "inherit from" the Default Frame Style (and show that fact in the "Inherit From" control in the Organizer tab. 3. "Standard" button would behave "standardly" (i.e., set values of the current tab to the Style shown in "Inherit From")
In the 'Inherit From' dropdown box "- None -" should be removed and "Default Frame Style" should be added.
Frame styles have some unresolved problems in regard to anchor type: bug 113381 text:anchor-type from style is not used Bug 36535 - EDITING: Updating of Frame Style not working correctly, anchoring to character do not updates For more problems see bug 108357 Further problems: Frame styles are used to distinguish a Writer text frame from a Draw text box, although that is not given in file format. A fixed, dedicated frame style is used for the text box in a custom shape. Further discussions are also in bug 140424. I would not touch inheritance until at least the anchor problem is solved.
Like with the Character Style questions (bug 140818), the background issue that motivated the suggestions is to find a good tooltip for the "Set to Parent" button. The suggestions in comment 0 were an attempt to make Frame Style be parallel to Paragraph Style (so that the same tooltip could be used), which is currently planned as: Set values shown in this tab to the values for the style specified in “Inherit From” in Organizer. Given the discussion in comment 2, the question becomes: How to describe what happens when "Set to Parent" is used, and "None" is the value in Inherit From? (this is the situation for all the builtin frame styles - and actually, in principle, it is also possible for a Paragraph Style). Based on experiments with Frame styles, my guess: When "Inherit From" has value "None", then values in Contains are removed.
I would reat this as enhancement request / question and I think, design team should decide cc: Design-Team
I wonder if we could just show the None or No Frame Style or Default Frame Style in the list without touching the inheritance. Can we, Mike? Btw, same problem at the table style - though with clearly no inheritance.
(In reply to Heiko Tietze from comment #5) > I wonder if we could just show the None or No Frame Style or Default Frame > Style in the list without touching the inheritance. Can we, Mike? This is basically what comment 1 suggests: > In the 'Inherit From' dropdown box "- None -" should be removed and "Default > Frame Style" should be added. But this is wrong or not easy. The suggestion tries to mimic fake default character style, but the latter is the metaphor for "nothing set; inherit everything from paragraph". So "nothing set on character style level" has a well-defined source for each character property. In case of other styles, like frame styles (and paragraph styles btw), the root of inheritance takes all its *fallback* values from global defaults. The "fake default" would have to show all the global defaults, even if not modifiable. Being unable to modify those would raise questions (valid btw, since hardcoded defaults is poor IMO). That would raise need of exposing the global defaults also on paragraph styles, since current "default" paragraph style is a proper style. If you instead introduce a normal "default" frame style, you will need to keep None, since being able to have multiple style hierarchies is a feature. And that introduced default style would still define nothing in itself, so it will still fallback to global defaults, so the (imagined IMO) problem discussed here will stay.
(In reply to Mike Kaganski from comment #6) By the way, *mostly* unrelated, but which IMO would make the distinction clear: I would propose to rename (again) "No Character Style" to "Paragraph Properties", and make it grey in list. That would show the unique nature and real purpose of this pseudo-style, and also allow to see why this metaphor doesn't fit in case of other styles.
So how about disabling the Standard button in case of frames (and where ever it also wont apply), Seth?
(In reply to Mike Kaganski from comment #7) > I would propose to rename (again) "No Character Style" to "Paragraph > Properties", and make it grey in list. Sounds good to me, perhaps "Follow Paragraph Properties". But why "again"? Haven't read this idea before.
(In reply to Heiko Tietze from comment #8) Why would it not apply to frames? Frames support inheritance, so user has an option to create own hierarchy. Also the reset button works even when there's no parent - it resets to global defaults. It *could* be reasonable to change the title dynamically - either to mention parent, or defaults... but IMO the better would be to revert the recent rename, and instead provide good tooltip explaining what it does depending on inheritance.
(In reply to Mike Kaganski from comment #10) > Also the reset button works even when there's no parent > - it resets to global defaults. Assume you mean "Reset to parent" button (and not "reset"). > but IMO the better would be to revert the recent rename, ?? is there a recent rename for Frame styles? > and instead provide good tooltip explaining what it does > depending on inheritance. Existing tooltip does that. (also for -None- case.)
Created attachment 177045 [details] Screenshot of style dialog - 7.1 vs 7.2 (In reply to sdc.blanco from comment #11) > (In reply to Mike Kaganski from comment #10) > > Also the reset button works even when there's no parent > > - it resets to global defaults. > Assume you mean "Reset to parent" button (and not "reset"). Yes, sorry for confusion :-) > > but IMO the better would be to revert the recent rename, > ?? is there a recent rename for Frame styles? Yes - see attached :-) > > and instead provide good tooltip explaining what it does > > depending on inheritance. > Existing tooltip does that. (also for -None- case.) The tip tells: "Values on this tab specified in "Contains" in Organizer are removed". It is technically correct, but does not give a tip which values will be used instead (and that is different for character styles vs other types of styles in "none" case) :)
(In reply to Mike Kaganski from comment #12) > Yes - see attached :-) Thanks. Noticed that FALSE, but did (do) not understand it (and no mention in Release Notes), so ignored it. > The tip ...is technically correct, but does not give a tip which values > will be used instead. Do you have a recommendation/suggestion? (I do not know the hardcoded defaults) Alternatively -- see title of this bug -- which is formed as a question. If there was a "Default Frame Style" (even if it was just equivalent to the hardcoded defaults), then the user would know what happens with "reset to parent", plus could modify the values for the "default FS" as needed. (I understand that there can be multiple style hierarchies, and -none- would still be needed, but no obvious problem in relation to the OP -- to improve the understanding of what happens when "Reset to parent" is used.) (btw, this seems to be how PS is currently handled. All PS inherit from Default Paragraph Style in the style hierarchy (where Default PS inherits from -none-)).
(In reply to sdc.blanco from comment #13) > Noticed that FALSE, but did (do) not understand it (and no mention > in Release Notes), so ignored it. FALSE is absolutely unrelated. We were discussing the *rename of the button*, which is what I tried to show there. > > The tip ...is technically correct, but does not give a tip which values > > will be used instead. > Do you have a recommendation/suggestion? > (I do not know the hardcoded defaults) "... Corresponding values from parent style, or program defaults if there's no parent, will be used." > Alternatively -- see title of this bug -- which is formed as a question. > If there was a "Default Frame Style" (even if it was just equivalent to the > hardcoded defaults), then the user would know what happens with "reset to > parent", plus could modify the values for the "default FS" as needed. > > (I understand that there can be multiple style hierarchies, and -none- would > still be needed, but no obvious problem in relation to the OP -- to improve > the understanding of what happens when "Reset to parent" is used.) You mix several concepts freely, and it's very difficult to discuss this way. *If* you suggest some "equivalent to the hardcoded defaults", then no, -none- would *not* be still needed. If you propose that "equivalent to the hardcoded defaults" to be also user-sditable, it's a big change. If you do not propose that, as you write in the following part: > (btw, this seems to be how PS is currently handled. All PS inherit from > Default Paragraph Style in the style hierarchy (where Default PS inherits > from -none-)). ... then you are just shifting the goalpost, because for default paragraph style, the button still has unclear (for user) behavior, and you do not fix anything. Additionally, multiple hierarchies without common root is not a solution - so suggestion to only provide common parent for "each **builtin** Frame Style" - would be just a false fix, which would pretend to fix something, but would keep the same problem for non-builtin styles, as if that improves things.
As an incremental improvement: Rename "Frame" to "Default Frame Style" (with no inheritance changes). Reasons: (a) would appear at the top of the list in the sidebar (when "All Styles" or "Hierarchical" views are used) (b) would be more consistent with Paragraph, Table, Page -- which also have "Default" (which also appear at top)
(In reply to sdc.blanco from comment #15) Disagree. "Default" styles in other places are created specifically to be roots of (possibly large) hierarchies. They control properties common for their descendants. They also generally considered to be a poor choice to use directly (at least, in Writer's paragraph styles). The "Frame" style is just something to use with frames (Insert->Frame), while "Graphics" is the default for "Insert->Image", etc. This proposal serves *no*, absolutely no purpose. Its reasons are wrong: (a) this style *does not need* to be at the top - it is just another style; (b) and it would *not* be consistent with other style categories that way - because of the abovementioned reasons.
(In reply to sdc.blanco from comment #15) Note that table "styles" are not styles, but some half-baked misfeature. The proper implementation of table styles is still completely lacking. So please do *not* use table styles for *any* comparisons - whatever is in the table styles is not relevant.
(In reply to Mike Kaganski from comment #16) > The "Frame" style is just > something to use with frames (Insert->Frame), while "Graphics" is the > default for "Insert->Image", etc. Got it. I was mislead by the fact that the window is called "Frame Styles". Is there a better generic name that could be used to describe the different kinds in the current "Frame Styles" list?
(In reply to sdc.blanco from comment #18) > Is there a better generic name that could be used to describe the different > kinds in the current "Frame Styles" list? A frame is a frame, and renaming would make everything rather worse. Looking at your original intention I think we should resolve this ticket as WF. Having hierarchical relations has some bugs, there is no Default nor it should be, and frames have no "None" in terms of "take attributes from parent" option like CS. (In reply to Regina Henschel from comment #2) > I would not touch inheritance until at least the anchor problem is solved. (In reply to Mike Kaganski from comment #6) > (No) "fake default" behavior (like at CS) (In reply to Mike Kaganski from comment #16) > "Default" styles in other places are created specifically to be > roots of (possibly large) hierarchies.