Bug 127080 - Improve handling of user-defined colors
Summary: Improve handling of user-defined colors
Status: RESOLVED DUPLICATE of bug 84579
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
6.3.0.4 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Color-Picker-Dialog
  Show dependency treegraph
 
Reported: 2019-08-21 10:33 UTC by Ulrich Windl
Modified: 2019-09-25 09:13 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Color selector used for fonts (10.14 KB, image/png)
2019-09-12 06:50 UTC, Ulrich Windl
Details
Color selector used for "area" in style definition (46.52 KB, image/png)
2019-09-12 06:52 UTC, Ulrich Windl
Details
Color selector offered in Tools->Options (66.08 KB, image/png)
2019-09-12 06:53 UTC, Ulrich Windl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Windl 2019-08-21 10:33:17 UTC
There is no easy way to see/check/modify the definition of a user-defined color in LO:
You have to open die Palette dialog, click on the user-defined (or any other) color.
Then the color is selected and the dialog closes. (even on single-click)
So you have to open the dialog again and select "user-defined color" to see the values of the color you selected last.
That's quit uncomfortable.

Solutions:
A single click in the palette dialog selects the color without closing the dialog, while a double-click will select and close. So you can hit user-defined color to check the values and/or modify it before accepting.
Alternatively a double-click on the color would open the user-defined color edit dialog. to allow editing. However a different action is needed to accept that color.
Independent of that when hovering over a color (currently the name is being shown), detailed color information (like RGB, Lch (HSB), CMYK, etc.) could be added to the hover box.
Comment 1 Thomas Lendo 2019-09-11 21:07:00 UTC
Ulrich, can you please explain which dialog you mean with "palette dialog"? And what's a user-defined color? The "custom color palette" or the "custom color" button in one of the color widget buttons in the toolbar/notebookbar/sidebar?
Comment 2 Ulrich Windl 2019-09-12 06:49:59 UTC
(In reply to Thomas Lendo from comment #1)
> Ulrich, can you please explain which dialog you mean with "palette dialog"?

I though there is only one, but actually there are at least three (Adding this comment I realized that all of those seem to prevent taking screen shots in GNOME and GIMP). Interestingly there is no menu in global options to manage palettes or colors, only the set of colors used for charts.

I'll attach the palette dialogs in a moment.

> And what's a user-defined color? The "custom color palette" or the "custom
> color" button in one of the color widget buttons in the
> toolbar/notebookbar/sidebar?

A color is not a button: A "user-defined color" is some specific color the user wants to use more than once, so preferably stored in some palette under a selectable name.
Comment 3 Ulrich Windl 2019-09-12 06:50:49 UTC
Created attachment 154122 [details]
Color selector used for fonts
Comment 4 Ulrich Windl 2019-09-12 06:52:26 UTC
Created attachment 154123 [details]
Color selector used for "area" in style definition
Comment 5 Ulrich Windl 2019-09-12 06:53:17 UTC
Created attachment 154124 [details]
Color selector offered in Tools->Options
Comment 6 Thomas Lendo 2019-09-22 19:07:54 UTC
Adding needsUXEval.

(In reply to Ulrich Windl from comment #0)
> Then the color is selected and the dialog closes. (even on single-click)
> So you have to open the dialog again and select "user-defined color" to see
> the values of the color you selected last.
> That's quit uncomfortable.
I don't see any benefit for the most users if the dialog keeps open which would result in an additional action for all users that don't want this behavior.
> Solutions:
> A single click in the palette dialog selects the color without closing the
> dialog, while a double-click will select and close.
Your suggestion seems to be a behavior that users are not familiar with. In other programs it behaves as LibreOffice does now.
> Independent of that when hovering over a color (currently the name is being
> shown), detailed color information (like RGB, Lch (HSB), CMYK, etc.) could
> be added to the hover box.
See bug 108751.
Comment 7 Cor Nouws 2019-09-22 21:11:36 UTC
(In reply to Thomas Lendo from comment #6)
> > Solutions:
> > A single click in the palette dialog selects the color without closing the
> > dialog, while a double-click will select and close.
> Your suggestion seems to be a behavior that users are not familiar with. In
> other programs it behaves as LibreOffice does now.
Yes, I see the same problem, Ulrich.
I think the current little inconvenience is better then changing the behavior.
Comment 8 Heiko Tietze 2019-09-23 05:47:33 UTC
User-defined colors are stored in an extra palette, just select the Custom palette. There you can single click on entries and get the respective RGB/Hex values right hand.

If you expect the picker itself (the floating widget that shows up on click at the sidebar) to behave like this I disagree. Its purpose is to select quickly a color and not to manage it. The idea of RGB values in the tooltip makes sense and has been file in bug 84579 (maybe other as well).

Here is the blog post when we started with the work
https://design.blog.documentfoundation.org/2015/12/22/area-fill-options-made-consistent/

(In reply to Ulrich Windl from comment #5)
> Created attachment 154124 [details]
> Color selector offered in Tools->Options

This is a left-over from the not yet finished work.
Comment 9 Heiko Tietze 2019-09-25 09:13:16 UTC

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