[Libreoffice-ux-advise] [Bug 87538] COLOR PICKER: New default color palette

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=87538

--- Comment #8 from Jay Philips <philipz85 at hotmail.com> ---
(In reply to Owen Genat from comment #6)
> - We should not be limiting users from creating custom palettes with greater
> than 8 rows or a set number of swatches. The user mailing list has some
> threads with very large palette file attchments containing many hundreds of
> swatches. I am not a fan of these SOCs but people do create and use them.
> For example, it would be unlikely that the Inkscape palette would fit within
> 8 rows.

There hasnt been any discussion in this bug report about limiting the number of
rows to 8 for custom palettes. We were discussing what the default palette
should be and ideally how many rows it should occupy.

> - A scrollbar should appear for palettes with a greater numbers of rows than
> can be displayed. If anything the color picker dialog should resize, as
> possible, to display the largest number of rows / swatches.

The scrollbar does appear when there are more than 10 rows in a palette, so
there isnt a need for the dialog to resize to accommodate more rows. The dialog
currently takes up 360 pixels, which is 40% of my screen height, and each color
row takes up 18 pixels. Available palettes that are more than 10 rows are
web.soc (20 rows), scribus.soc (46 rows), cmyk.soc (18 rows), html.soc (11
rows), and standard.soc (14 rows).

> - Palette swatches in the current standard.soc affect legacy documents.
> There would at least need to be a separate palette created to include the
> excluded swatches. This could easily become messy.

We discussed this issue in the weekly design meeting a few weeks back and it
will not negatively effect legacy documents, as the colors are stored in the
documents as their rgb values, but yes we should duplicate the current
standard.soc as a new palette file if we change the default palette.

> - Given the format of the XML entries it is both more logical and easier IMO
> to create palettes on a hue-per-row than hue-per-column basis. I explain the
> reasons for this in bug 80196. It certainly makes it easier to have a block
> of entries named "10% Magenta", "20% Magenta", rather than have such entries
> broken up one to a block.

The XML format simply provides the details of the palette colors, but not the
manner in which it should be displayed. Most color palettes have gradients
going top to bottom or bottom to top and i feel that is best to stick with this
norm. Even LO's color picker dialog shows it in this manner when hue,
saturation or brightness are selected.

> - Unless the colour picker layout reaches some sort of stability (so far
> there is no sign of this occurring) the number of rows displayed and the
> creation of SOC files to suit a given layout will remain problematic.

I think SOC files should define the number of columns per row, so that color
palettes which were designed with a specific number of entries per row that
isnt 12 (e.g. 10 or 16) can be shown as they were designed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.