Issue 104429 - General Enhancements to Options>> Colors
Summary: General Enhancements to Options>> Colors
Status: CLOSED DUPLICATE of issue 65778
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: OOO310m11
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: requirements
QA Contact: issues@framework
Keywords: oooqa
Depends on:
Reported: 2009-08-22 17:20 UTC by evilashe
Modified: 2009-10-07 18:43 UTC (History)
2 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description evilashe 2009-08-22 17:20:28 UTC
I just finished designing the layout for a rather large spreadsheet in Calc,
encompassing about 150 columns.  These columns needed to be sequentially
color-coded, primarily, to signfy the data's logical categorizations.

Since I didn't want to be bothered with the added consideration (and readability
enhindrances) of varying font color by darkness, our spreadsheet is using
numerous ranges of softer colors that allow for easy reading with a default
black-colored font.

For such a quantity of soft-colored, categorized columns, the rather scant
default swatch must be ammended (in Options > OpenOffice.Org > Colors) with at
least several dozen new colors, and they must be sequential in some way, rather
than a hodge-podge of random colors butting next to each other.  The
much-appreciated left-hand 8x8 gradient was used to help manually select these
colors by ascending brightness.

Here are my suggested enhancements:

(1) Problem: The current 8x8 gradient that is provided in the "Color" window
becomes very bothersome in the fact that it wants to constantly choose a default
color gradient every time its window is opened (via "Edit..." button). 
Therefore, the color gradient, in order to ensure consistency in my
spreadsheet's coloring scheme, had to be manually re-defined every time.

Solution: Can't we have this gradient simply remember its previous settings?

(2) As it currently is, the UI methodology for altering this color table is
unintuitive, at best.
  (a) The user should not be able to alter color information (i.e. Name, RGB)
directly, but would have a separate window that does the jobs of both editing
and creating new colors.  See (b) for this.  Instead, this table, therefore,
will allow the user to re-arrange (move) colors, select individual colors (for
editing), or select multiple colors (for deletion or moving) using SHIFT and/or
CTRL for selection.  Drag and drop for this table would be nice too.
  (b) The color selection window that opens from the "Edit..." button should be
expanded to include an input field for the color's Name, as well as the "Old
Color" box and the "New Color" box (or "Current" and "Pending"?).
  (c) The current "OK" button in the expanded window from (b) should be replaced
with two buttons: "Apply Changes," which saves changes (made to a pre-existing
color only), and "Add Color"
  (d) The current "Modify" button should be removed completely.  Its
functionality (as an 'apply change now' button) would be replaced with the
expanded window's "Apply Changes" button from (b).  "Modify" and "Edit" are
synonyms in English, and should not appear in the same window.
  (e) The "Old Color" or box should be moved from the Options window into the
expanded "Color" window proposed in (b).  It should also be labelled to reduce
  (f) An "Add Color..." button would take the user to the same expanded
"Edit..." window as in (b), but with no color Name or color information
pre-populated.  As described in (b), the user would then enter information and
select the "Add Color" button when finished.
  (g) The humbly-named, expanded "Color" window from (b) should be retitled
"Add/Edit Color" for less ambiguous reference in the future.
  (h) Possibly, the left-hand (and currently 8x8) gradient could have two small
fields (both with default "8") that control from how many units this gradient is
composed.  Someone, somewhere might want this, and it seems simple enough.

(3) Perhaps an "import from file" button should be added.  X11 users, e.g.,
might want to import their standard list of colors.  Let's not get really
granular about the import file format -- the user might have to do some
reformatting to their text file, but it would be far easier than entering a
hundred colors manually.

Thanks for reading!
Comment 1 Olaf Felka 2009-08-24 07:29:43 UTC
@ wg: Please have a look.
Comment 2 wolframgarten 2009-08-24 07:45:07 UTC
Comment 3 ace_dent 2009-10-07 18:41:28 UTC
Hi evilashe

Thanks for taking the time to make so many useful suggestions. However, we
exercise a policy of one request for enhancement per Issue. It seems your
principle issue duplicates this:
Issue 65778 - Automatic ordering of colors (by hue, number, etc.) in palette

To manage the many suggestions for enhancing the color palette, I have created a
meta-issue here:
Issue 105642 - Re-design and UI improvements for color palettes.

The purpose of the new issue is for management only, it does not duplicate
specific design requests (that we wish to capture).

We would really value your input. If you'd like to look over the issues, and add
any comments you've raised here, that's great. Equally, if you have an idea
/problem that hasn't been covered elsewhere, please raise a new Issue (but just
one enhancement per Issue!).

Many thanks,

*** This issue has been marked as a duplicate of 65778 ***
Comment 4 ace_dent 2009-10-07 18:43:16 UTC
Closing as a duplicate.