Description: Headings created as child of say Heading 1 behave different from Heading 1 Steps to Reproduce: 1. Open Writer 2. Sidebar -> Paragraph styles 3. Double click heading 1 4. Type HEADING in document 5. Press Enter.. 6. Type AAA (formatting will be textbox) 7. CTRL+Z everything 8. Right click heading 1, click NEW 9. Type a name (say AAA) 10. Double click AAA in sidebar 11. Type HEADING 12. Press Enter 13. Type AAA (will be heading formatting) Actual Results: Heading formatting Expected Results: Consistency. No strong opinion what would be correct. (I assume what happens at 1-6; looking at Word) Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 96d1240adf946c443fb2c369a1c84e31e259c7a8 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL
Same in Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL
And in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
(In reply to Telesto from comment #0) > Description: > Headings created as child of say Heading 1 behave different from Heading 1 > > Steps to Reproduce: > 12. Press Enter > 13. Type AAA (will be heading formatting) Yes, because next style in Style "AAA" is "AAA" by default. So works as expected. So question is, if next style should be taken from the inherited style by default, if you create a new style based on an existing one. So if you agree, Telesto, we should treat this as enhancement and change bug summary.
(In reply to Dieter from comment #3) Thanks for the analysis :-) Let's ping UX
We inherit everything on creating a new style but the following style. Don't see a good reason for this. Do you, Mike?
(In reply to Heiko Tietze from comment #5) No preference. Possibly current state looked reasonable to someone - or the other way round was confusing to someone. Fine by me to experiment changing this. Just make sure that if the next points to itself, then the new style's next should point to the new style, not the one that was the "template".
(In reply to Mike Kaganski from comment #6) > Just make sure that if the next points to itself, then the new style's next > should point to the new style, not the one that was the "template". Good point :-)
We inherit property values, but is next style a property value, or just a setting. Likely it is just a setting, just like name, autoUpdating, hidden, etc. I believe this is defined in class SW_DLLPUBLIC SwTextFormatColl with SwTextFormatColl *mpNextTextFormatColl; So I would consider this NOTABUG, especially since nothing else on this tab is inherited.
(In reply to Justin L from comment #8) > We inherit property values, but is next style a property value, or just a > setting. Likely it is just a setting, just like name, autoUpdating, hidden, > etc. > So I would consider this NOTABUG This is a developer perspective. I assume user perspective is different. > especially since nothing else on this tab is inherited. I won't expect that name is inherited and Custom Style is also expected by definition. So for me not an argument.
(In reply to Justin L from comment #8) The request here is not about inheritance as implemented for style properties, where each property may be defined in the style itself, or taken from its parent style. The request uses the word "inherit" together with "when creating a new style", asking for taking the value of the setting at the creation time. And that is doable, without any change in style machinery; IMO it's purely UX question to do or not to do :-) - it's not a problem from implementation PoV.
Things are the same as reported by Telesto. By default, for any new style, it is easier to have the same style on the next style. Maybe this exception could be made just for Headings (1-10), where, the next style to be "Text Body". Retested with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f92721bf182952be88b0349a17e46b684d630c29 CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded