Download it now!
Bug 130953 - Improve listing of (table) styles to reflect that newly created styles are in the document only (not available elsewhere)
Summary: Improve listing of (table) styles to reflect that newly created styles are in...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Sidebar-Styles Table-AutoFormat Writer-Table-Insert-Dialog
  Show dependency treegraph
 
Reported: 2020-02-26 10:02 UTC by Timur
Modified: 2020-03-06 09:59 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Timur 2020-02-26 10:02:30 UTC
When adding new table style via Sidebar-Styles-Table Styles with + and "New Style from Selection", it appears in Sidebar-Styles-Table Styles but not in Table-Insert Table-Styles nor in Sidebar-Styles-Table Styles of a new document.
Doesn't look OK to me. 

When adding AutoFormat table style via right-click and Add, it appears in Format list of styles and in Sidebar-Styles-Table Styles and it is available in Table-Insert Table-Styles.
That's OK, as explained in https://help.libreoffice.org/7.0/en-US/text/swriter/01/05150101.html.
Comment 1 Maxim Monastirsky 2020-02-26 10:47:44 UTC
(In reply to Timur from comment #0)
> nor in Sidebar-Styles-Table Styles of a new document.
This part is OK. The same would happen with other style kinds (paragraph, character etc.), as the sidebar panel operates on the styles of the current document, unlike the AutoFormat dialog which operates on formats stored in the user profile. If anything, I would just get rid of the AutoFormat dialog, and let users define styles in templates, instead of storing them in a dedicated file inside the user profile.
Comment 2 Heiko Tietze 2020-03-02 17:12:12 UTC
(In reply to Maxim Monastirsky from comment #1)
> I would just get rid of the AutoFormat dialog

Agreed, and this is actually what we planned but I cannot find the respective ticket. Anyway, the fact of document related vs. permanent styles should be documented better. Or the ticket is just a WFM.
Comment 3 Maxim Monastirsky 2020-03-02 21:11:37 UTC
(In reply to Heiko Tietze from comment #2)
> (In reply to Maxim Monastirsky from comment #1)
> > I would just get rid of the AutoFormat dialog
> 
> Agreed, and this is actually what we planned but I cannot find the
> respective ticket. Anyway, the fact of document related vs. permanent styles
> should be documented better.
Yes, but shouldn't in the meantime the Table > Insert Table... dialog be changed to list the document styles instead of the permanent styles? I believe that what this bug was mostly about.
Comment 4 Heiko Tietze 2020-03-03 06:59:20 UTC
(In reply to Maxim Monastirsky from comment #3)
> Yes, but shouldn't in the meantime the Table > Insert Table... dialog be
> changed to list the document styles instead of the permanent styles? I
> believe that what this bug was mostly about.

Or rather both with some smart indication which style is permanent. Point is that users cannot know where the style is stored.
Comment 5 Cor Nouws 2020-03-04 19:03:22 UTC
(In reply to Heiko Tietze from comment #2)
> (In reply to Maxim Monastirsky from comment #1)
> > I would just get rid of the AutoFormat dialog
> 
> Agreed, and this is actually what we planned but I cannot find the
AutoFormat is in use in Calc.
So currently there is consistency - but at what price.
Should need so time to think about this..
Comment 6 Heiko Tietze 2020-03-05 07:05:17 UTC
We discussed the topic in the design meeting. 

The issue is less relevant for other styles since paragraph styles are always stored in the document. So it's a solution when we get rid of the autoformat dialog (don't find a respective ticket). However, since table styles might be installed per extension (see also bug 124046) the situation is less clear, and actually it would be good to have the same opportunity for all styles. 

Simple solution to distinguish system from user styles is to show the latter on the bottom after a horizontal ruler.
Comment 7 Maxim Monastirsky 2020-03-05 12:46:53 UTC
(In reply to Heiko Tietze from comment #6)
> However, since table
> styles might be installed per extension (see also bug 124046) the situation
> is less clear
Why less clear? I would assume that styles from extensions will be visible in all documents (as long as the extension is installed), so where is the problem?

> Simple solution to distinguish system from user styles is to show the latter
> on the bottom after a horizontal ruler.
Why is there any need to distinguish system styles from user styles? From a user perspective of applying styles to tables, there is really no difference between system and user styles, as they work the same.

Also, once a system style is applied, it's exported into odf, and from now on whatever is stored there is used, and actually overrides the system style of the same name. Which means that putting user styles under a horizontal ruler would just move there all used styles in existing documents. Of course, we might not put under the ruler user styles with the same names as the system ones. But then it even less clear why this kind of separation is useful, as styles can also be modified, and so styles with the same name might be actually different in different documents. If anything, an icon near a system style might be a better option, but again, I don't see any point in doing this either.

This also can't be an alternative to removing the autoformat dialog. It indeed might be less confusing in the scenario of newly created user styles, but what about manipulation of existing styles? Using the dialog, styles can be removed or renamed, but this isn't reflected in the sidebar of the current document. Also the other way, existing styles can be updated from selection with the sidebar, but this isn't reflected in the dialog (e.g. the preview will be based on system data instead).

Technically, system styles are appended to the document styles once the sidebar is opened for the first time. From that point, they are document styles by any mean. That's why any changes made to the system storage afterwards are not reflected there, as those two lists already diverged at this point. All of this won't be of a concern once the autoformat dialog is removed, as that would mean that users will no longer have a way to modify the system styles (much like they can't modify paragraph system styles).
Comment 8 Thomas Lendo 2020-03-06 00:55:52 UTC
Heiko, so you mean bug 49437 or bug 116091?
Comment 9 Heiko Tietze 2020-03-06 09:59:34 UTC
(In reply to Thomas Lendo from comment #8)
> Heiko, so you mean bug 49437 or bug 116091?

Non of the two is about removing the autoformat dialog.