Bug 108669 - UI: The default blue area fill color isn't pre-selected in the color picker palette
Summary: UI: The default blue area fill color isn't pre-selected in the color picker p...
Status: RESOLVED DUPLICATE of bug 108670
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Color-Palettes
  Show dependency treegraph
 
Reported: 2017-06-21 09:53 UTC by Telesto
Modified: 2020-05-18 17:06 UTC (History)
4 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 Telesto 2017-06-21 09:53:17 UTC
Description:
The default blue area fill color isn't pre-selected in the color palette (seems inconsistent). Fills for Gradient, Bitmap, Pattern, Hatch are pre-selected in the corresponding picker. The color is also selected in the color picker if a new color is applied


Steps to Reproduce:
1. Format menu -> Page -> Area fill tab -> Color button


Actual Results:  
1. The blue color isn't pre-selected in the color palette 


Expected Results:
1. The blue color should be pre-selected in the color palette



Reproducible: Always

User Profile Reset: No

Additional Info:
Version: 6.0.0.0.alpha0+
Build ID: cbf371e07fd5dea1ea08a1f299360d1273961ebd
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-06-14_23:13:57
Locale: nl-NL (nl_NL); Calc: CL


User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Comment 1 Cor Nouws 2017-06-21 13:28:01 UTC
maybe bug 105740?
Comment 2 Telesto 2017-06-21 14:06:55 UTC
(In reply to Cor Nouws from comment #1)
> maybe bug 105740?

Nope, I checked (an verified with latest daily). This one is about the initial state when opening the arena dialog for an empty document. A blue background color is preset as "NEW", but not selected in the color picker.
Comment 3 Katarina Behrens (Inactive) 2017-06-21 21:51:54 UTC
The colour is not preselected as someone thought it would be a brilliant idea and improved UX when standard colour aka Tango Blue aka #729FCF was removed from standard colour palette 

It has moved to 'tango' pallete, which would then have to become standard
Comment 4 Cor Nouws 2017-06-22 20:11:04 UTC
(In reply to Katarina Behrens (CIB) from comment #3)
> The colour is not preselected as someone thought it would be a brilliant
> idea and improved UX when standard colour aka Tango Blue aka #729FCF was
> removed from standard colour palette 

I think that is more a mistake, something that has been overseen.
Comment 5 Thomas Lendo 2018-01-10 09:46:03 UTC
Light Blue 3 (#7DA7D8) of the current default color palette can be used instead of #729FCF. Seems to be the most similar color of the palette.
Comment 6 Thomas Lendo 2018-01-10 09:47:54 UTC
And Blue (#0066B3) instead of #3465A4 for the line color.
Comment 7 Yousuf Philips (jay) (retired) 2018-01-10 20:38:22 UTC
The default blue area fill or stroke/border colors dont need to be part of the default palette in my view, so no this wasnt a mistake when we changed the standard palette.
Comment 8 Thomas Lendo 2018-01-10 23:24:34 UTC
For me it looks better and consistent when all default colors are part of the standard palette. Same as text highlight and font color.
Comment 9 Cor Nouws 2018-02-04 16:07:10 UTC
(In reply to Thomas Lendo from comment #8)
> For me it looks better and consistent when all default colors are part of
> the standard palette. Same as text highlight and font color.

I agree. And in fact, for users friendliness, older default fill colors should be in there too (After all, we don't change that so often :)  )
Comment 10 QA Administrators 2019-02-05 03:46:49 UTC Comment hidden (obsolete)
Comment 11 Cor Nouws 2019-05-11 13:03:57 UTC
works fine in Version: 6.3.0.0.alpha0+
Build ID: 98630a0bd49bd80652145a21e4e0d0ded792b36b
CPU threads: 4; OS: Linux 5.0; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-04_04:44:35
Locale: nl-NL (nl_NL.UTF-8); UI-Language: en-US
Calc: threaded
Comment 12 Thomas Lendo 2019-05-15 20:35:26 UTC
Cor, I can reproduce this issue with

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

"blue color isn't pre-selected in the color palette" means that there is no selection border in the palette on the left half of the Area color tab although the blue color is really selected (if you click OK the page will be blue colored and the blue color is previewed in the "New" column at the right of the Area color tab.
Comment 13 V Stuart Foote 2020-05-18 17:06:08 UTC
Going to dupe this to bug 108670, issues are the same. 

Opening the Area -> Color panel arriving from another Area type, especially default 'None' mode, opens the Active Color with no actual assigned color--and incorrect indicator of what would be assigned.

The GUI shows a Black (#ffffff) swatch, but with default 114, 159, 207 RGB values for #729fcf Area fill (Old Tango: Sky Blue 1, now Light Blue 2 on Standard palette).

Once the New color #729fcf, or another pick from pallet or custom pick made, is applied--the GUI will refresh. If pick is made from Standard palette or swittched to and made from another installed pallet--the indicator on the palette swatches will show the pick.

Until a pick is made and applied the color Swatch is wrong, while the lack of an swatch indicator on the pallet GUI--could be seen as correct, no Color has been selected/applied yet--but would be more consistent UI to show what would be applied.

Work on bug 108670 should resolve this with a better null color assignment, tweaking the UI to either symbolize the null area fill.

*** This bug has been marked as a duplicate of bug 108670 ***