Right, colors shouldn't be shown until the use has assigned a style with color to a cell.

In Writer it's the same. I think that was desired or forgotten when programmed because default style has no color until now. You can test it: Change the color of a default Writer style and don't apply it to a text - the color will be shown in the 'document colors' palette. That's a false behavior.

I plead for the same behavior in all LibO components in this case. Changing component to "LibreOffice" instead of "Calc"?

(In reply to Thomas Lendo from comment #1)
> In Writer it's the same. I think that was desired or forgotten when
> programmed because default style has no color until now. You can test it:
> Change the color of a default Writer style and don't apply it to a text -
> the color will be shown in the 'document colors' palette. That's a false
> behavior.

If you change the color of the default paragraph style, then it should be in the 'document colors'. This is the correct behaviour. In Writer we have colors on character styles like 'internet link', 'visited internet link', and 'placeholder', but those dont show up in 'document colors' when you create a new document.

(In reply to Yousuf Philips (jay) from comment #2)
> If you change the color of the default paragraph style, then it should be in
> the 'document colors'. This is the correct behaviour.
Document color palette should only show the colors of applied styles, not of not-yet-used style colors. Also Writer paragraph style colors shouldn't be shown until that style is applied to content - same behavior as with character styles.

Problem does not exist in 6.3 master.

Cor, this is not true. The issue still exists.
If I open a new spreadsheet document and go to the background or font color split button in the toolbar, then switching to "Document colors" shows all colors that are available in the cell styles (although these cell styles are not assigned to any cell of the document).

Version: 6.3.0.0.alpha0+
Build ID: 98630a0bd49bd80652145a21e4e0d0ded792b36b
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-04_04:44:35
Locale: de-DE (de_DE.UTF-8); UI-Language: en-US
Calc: threaded

*** Bug 128325 has been marked as a duplicate of this bug. ***

IMO NOTABUG.

How do you define "used"? Suppose you assign a color to a style used in a conditional format (Calc), or make it a conditional style (writer), and the condition is not satisfied - is it used, or not? Suppose it's used in another style - like in a header of a page style: is it used or not? And e.g., the page style using the colored style might not be assigned manually, but be part of a page style sequence defined by "Next style" machinery - and then its appearance depends on current page count, which may depend on a huge number of variables - e.g., on the length of dynamic fields, or content of linked frames, etc.

In general, I'd suggest to keep it simple: it is used in style defined in the document = it is used in the document.

(In reply to Mike Kaganski from comment #8)
> IMO NOTABUG.
> 
> How do you define "used"? Suppose you assign a color to a style used in a
> conditional format (Calc), or make it a conditional style (writer), and the
> condition is not satisfied - is it used, or not? Suppose it's used in
> another style - like in a header of a page style: is it used or not? And
> e.g., the page style using the colored style might not be assigned manually,
> but be part of a page style sequence defined by "Next style" machinery - and
> then its appearance depends on current page count, which may depend on a
> huge number of variables - e.g., on the length of dynamic fields, or content
> of linked frames, etc.
> 
> In general, I'd suggest to keep it simple: it is used in style defined in
> the document = it is used in the document.
There are two counter-argument to this:

1. Calc differentiates "all styles" and "applied styles" in the Style sidebar.  I think it would be much closer to the user's expectation that applied styles count as "document colors", while the others don't.  AFAIK it's not possible to define a conditional format without applying it to some cell range, so conditional formats can all be considered applied.

2. Currently Writer's default paragraph styles don't seem to use any colors, but the character styles do, e.g. the "Internet Link" style.  The color used by these character styles don't show up as document colors unless said character style is applied to some text.

(In reply to Ming Hua from comment #9)
> 1. Calc differentiates "all styles" and "applied styles" in the Style
> sidebar.  I think it would be much closer to the user's expectation that
> applied styles count as "document colors", while the others don't.  AFAIK
> it's not possible to define a conditional format without applying it to some
> cell range, so conditional formats can all be considered applied.

Then please do the natural experiment: on a new spreadsheet, select "Applied Styles" (only Default is shown); on A1, select Format->Conditional->Condition; define the condition as "Cell value is equal to 1" => apply style "Accent"; confirm and see that the applied styles list still only shows you the single "Default" format. It will not show you "Accent" even if you put "1" to A1, because "Applied" is very simple: it only shows those that are directly applied, not through some automated machinery. As said, it's not that simple.

Anyway, I generally disagree with any changes that psychologically split styles from document content. It makes styles more "voodoo magic", instead of the opposite goal of making styles the integral part of the document and user's workflow. So my disagreement is not only technical, but also methodological.

Note that this request focuses on just one side of the workflow: someone uses a default set of styles, and selects "document colors", and sees some (few) unexpected values there.

But implementing this proposal means that people are expected to *not* use styles as expected, because the following workflow is ignored: user creates a document (e.g. a spreadsheet), creates styles in it as they need, with colors they intend to use; and this intention is like painter preparing a palette. Not having those colors that user *declared explicit intention to use* on the palette of used colors is IMO absurd.

(In reply to Mike Kaganski from comment #10)
> Anyway, I generally disagree with any changes that psychologically split
> styles from document content. It makes styles more "voodoo magic", instead
> of the opposite goal of making styles the integral part of the document and
> user's workflow.
In general I agree with this direction of emphasizing the integral role of styles.

(In reply to Mike Kaganski from comment #11)
> But implementing this proposal means that people are expected to *not* use
> styles as expected, because the following workflow is ignored: user creates
> a document (e.g. a spreadsheet), creates styles in it as they need, with
> colors they intend to use; and this intention is like painter preparing a
> palette. Not having those colors that user *declared explicit intention to
> use* on the palette of used colors is IMO absurd.
One possible solution here is treating user-created styles differently than default styles.

---

No matter how the developers eventually decide, the annoyance is real: the users who use document colors a lot but seldomly uses styles will have to deal with 12 (IMHO not really "few") colors he/she wants to having nothing to do with.  And there is no way he/she can delete the default styles he/she doesn't use to get rid of these colors.

I personally have deviated away from directly applying colors and started using styles more since I reported the duplicate bug 128325.  So this bug doesn't affect me that much anymore.  But the question is, do we want to accommodate such less-than-ideal habits?  From the recent addition of "autofilter by text or cell colors" feature in 7.2, I would think the answer is yes.

---

P.S.: Just curious -- implementation work aside, would you support the idea of showing colors used by Writer's default character styles in document colors as well, Mike?

(In reply to Ming Hua from comment #12)
> P.S.: Just curious -- implementation work aside, would you support the idea
> of showing colors used by Writer's default character styles in document
> colors as well, Mike?

I would :) That would be consistent.

However, on the second thought, it *seems* that "Document colors" palette is explicitly targeting people who chose to *not* use styles. Because why otherwise would they need that palette? For someone who prepares styles, such a palette is most likely not needed; for someone who then uses styles, it's also not needed, because they use style list and entries listed there, not applies colors directly.

If that is true, then please disregard my comments above :)

(In reply to Mike Kaganski from comment #13)
> However, on the second thought, it *seems* that "Document colors" palette is
> explicitly targeting people who chose to *not* use styles. Because why
> otherwise would they need that palette? For someone who prepares styles,
> such a palette is most likely not needed;
> ...
Not necessarily true.
Someone may want to add or change a style  (or content), and use a color already in use in another style.
(Also, IMO using styles on objects/images/frames, is not always handy since it may mix properties as size/ration, with e.g. border and color - Unless I use it in a wrong way, of course...)

Dear Yousuf Philips (jay) (retired),

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug