Created attachment 111090 [details] what the new palette would look like The current default color palette (standard.soc) used in LO has 167 colors across 14 rows and this is way to many colors for users to choose from, and the new color picker drop down only showing 10 rows at a time also doesnt help the situation. I would like to suggest that we crop this list to 8 rows by taking the first 7 rows and row 12. Also in the first row, we should move the black color to the right end of the row so the gradient is consistent on that row.
Created attachment 111091 [details] color palettes used in other office suites
Created attachment 111092 [details] RGB color palette An alternative is to convert the attached palette into a suitable sized palette that suits our purposes. Likely 12x8. Palette taken from < http://websafecolorcodes.com/colors-palette/color-wheel-palette/ >
Created attachment 111095 [details] Color wheel base Another alternative is to simply use the attached color palette along with a white to black gradient row.
@Jay, *, I'm not opposed to this. But if the color picker at 12 columns but showing just 10 rows is a problem, it might be a better option to expand number or rows, or even columns shown. Q: what would be the best layout of the color picker to accommodate a new standard.soc pallet? And, regards the standard.soc pallet, two issues with that: 1.) kind of feel like we are obliged to support our LibreOffice branding, https://wiki.documentfoundation.org/Marketing/Branding#Color_Table most of which are in our standard.soc table now. Reworking as you suggest probably would require that we move this entire branding color chart into its own pallet--an addition to your bug 87541 suggestion. Leaving us free to reduce and adjust the standard.soc; 2.) Wade Peterson's did some very compelling work for a device neutral color pallet, in bug 80196 -- it could/should occupy the lower rows of the standard pallet. @Wade, @Owen opinions please... Stuart
(In reply to V Stuart Foote from comment #4) > I'm not opposed to this. But if the color picker at 12 columns but showing > just 10 rows is a problem, it might be a better option to expand number or > rows, or even columns shown. Expanding the number of rows doesnt solve the primary problem with the color palette, which is that there are two many colors in it. Most users need a small range of colors to choose from and now that we have the color picker dialog available in the drop down, those that want to choose an exact color now have easy access to doing so. > Q: what would be the best layout of the color picker to accommodate a new > standard.soc pallet? I believe the current layout of 12 columns is fine, as all three of the suggestions fit it. > 1.) kind of feel like we are obliged to support our LibreOffice branding, > https://wiki.documentfoundation.org/Marketing/Branding#Color_Table most of > which are in our standard.soc table now. Reworking as you suggest probably > would require that we move this entire branding color chart into its own > pallet--an addition to your bug 87541 suggestion. Leaving us free to reduce > and adjust the standard.soc; We have a libreoffice.soc and i would have assumed it does cover any colors related to the branding. > 2.) Wade Peterson's did some very compelling work for a device neutral > color pallet, in bug 80196 -- it could/should occupy the lower rows of the > standard pallet. Seems interesting and it would be great for Wade to fill in the upper rows so it could be put into an .soc file so it could be tried.
I tend to agree with Stuart. These are the problems I see: - 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. - 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. - Palette swatches in the current standard.soc affect legacy documents. There would at least need to - 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. - 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.
(In reply to Owen Genat from comment #6) > - 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.
(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.
(In reply to Jay Philips from comment #8) > (In reply to Owen Genat from comment #6) > > - 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. Actually that would be a very valid UI change for the ColorPicker. In https://bugs.freedesktop.org/show_bug.cgi?id=80196#c19 Owen had to rotate the pallet because that scheme would require 13 columns rather than the 12 he had to work with in demonstrating Wade's proposal. 8-10-12-13-16 columns all might result in appealing pallets to work with. Q: Can the Widget for the ColorPiker be made dynamic to respond to the .SOC? Q: Failing that, could we agree change the ColorPicker column count to match what ever best fits our new standard.soc?
(In reply to V Stuart Foote from comment #9) > Actually that would be a very valid UI change for the ColorPicker. > > In https://bugs.freedesktop.org/show_bug.cgi?id=80196#c19 Owen had to rotate > the pallet because that scheme would require 13 columns rather than the 12 > he had to work with in demonstrating Wade's proposal. 8-10-12-13-16 columns > all might result in appealing pallets to work with. When i looked at Wade's proposal, my first instinct was to have white to black as the first row of the palette and then have the colored ones going columns wise, as that is similar to how our current palette is now and white to black is not a color blend which could fit next to the other color range column wise. > Q: Can the Widget for the ColorPiker be made dynamic to respond to the .SOC? You would likely have to ask a dev familiar with the code to know this, but i dont think the drop down width changing multiple times when you go from palette to palette would be a good thing. What i think would work is that size of the palette color boxes change depending on the the number of columns per row. If we can set width of the palette color area to 230 pixels, we can accommodate 16 columns at 10x10, 12 columns at 14x14, and 10 columns 18x18 (these numbers are excluding the 2 pixels padding on the left and right of each color palette box). > Q: Failing that, could we agree change the ColorPicker column count to match > what ever best fits our new standard.soc? Yes it should primarily accommodate whatever is our default color palette optimally, as other palettes are secondary, though i believe that a 12 column palette will cover all the bases we need and we will have 3 other 12 column palettes also in the palette list (web.soc, cymk.soc, and the current standard.soc).
Came across a tweet today of someone doing a color palette based on google's material design colors. https://twitter.com/boky8/status/553123925497225216 I've created a #libreoffice color palette that does not suck, based on #materialdesign. Get it here: https://imgur.com/gb96Uoa
Created attachment 114210 [details] onlyoffice color palette stumbled on this today. :D
(In reply to Jay Philips from comment #12) > Created attachment 114210 [details] > onlyoffice color palette > > stumbled on this today. :D Details? Is it a .soc that you're proposing to add? Can you attach it, or you've only just a screen clip?
(In reply to V Stuart Foote from comment #13) > Details? Is it a .soc that you're proposing to add? Can you attach it, or > you've only just a screen clip? Saw it while i was watching this youtube video. https://www.youtube.com/watch?v=KZCzXZKWfzw&t=22
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
heiko tietze committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=765826abcaa441d4d90ffbe75bc3c626c42e639b tdf#87538 New standard color palette, tdf#104052 Add LibreColour HLC palette It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
heiko tietze committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=89488baf09d2e7580041462b409f587ce43af214&h=libreoffice-5-3 tdf#87538 New standard color palette, tdf#104052 Add LibreColour HLC palette It will be available in 5.3.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jay reopened the ticket because of missing pastel tones. Similar request comes from the blog post https://design.blog.documentfoundation.org/2016/12/30/new-color-palettes-in-libreoffice/#comments linking to http://www.imgup.cz/images/2016/12/30/proposal.png.
Created attachment 131330 [details] Screenshot of new standard palette With another algorithm to modify luminance it looks more flexible now. First lines are gray scale and basic colors, followed by saturation of 60%, 30%, and 15% and then luminance increased by 9.5, 7.5 and 5.0. Push or change?
Created attachment 131331 [details] Porposed new standard palette And the palette itself.
Created attachment 131342 [details] Perfect palette Hopefully the final version. Row #1: Grey scale (White, Gray 1..10, Black) #2 basic colors (Blue to Violet) #3 50% saturation (<Blue> 50% Sat) #4 25% saturation (<Blue> 25% Sat) #5 x8 luminance (<Blue> x8 Lum) #6 x5 luminance (<Blue> x5 Lum) x7 -x5 luminance (<Blue> x1/5 Lum) x8 -x8 luminance (<Blue> x1/8 Lum) Saturation is done per ColorRGBToHLS(), luminance with ColorAdjustLuma().
Created attachment 131343 [details] Perfect palette - soc And the soc file.
Created attachment 131468 [details] RYB 8 and 7 variants soc files
Created attachment 131469 [details] document with tables showing the RYB 7 and 8 variants
Created attachment 131473 [details] RYB screenshot Serious issue is that it has one line over the max. And I miss darker colors either by reduced lumination or saturation. Difference between RYB7 and 8 is unclear to me, 7 has better distribution with bright colors, 8 is better at darker. Both make rose and magenta rather a red and the red morphs into orange.
Created attachment 131474 [details] Extension with luminance variation If we go with a different standard palette the variations of saturation and luminance should be available as an extension.
Created attachment 131475 [details] Extension with saturation variation
Created attachment 131574 [details] how color widget looks for me (In reply to Heiko Tietze from comment #25) > Serious issue is that it has one line over the max. I have 9 rows, so not over the max. The max seems to have been jumping up and down between versions for some strange reason. > And I miss darker colors either by reduced lumination or saturation. We have a limited number of rows, so we can please everyone, we just need the colors to be sorted from lighter to darker. > Difference between RYB7 and 8 is > unclear to me, 7 has better distribution with bright colors, 8 is better at > darker. I find the colors better in 8, specifically the red's in 7 look more orangish. > Both make rose and magenta rather a red and the red morphs into orange. Rose and magenta are RGB colors variants and not RYB.
Created attachment 131869 [details] complete version of my proposal mentioned above
(In reply to tomaskeb from comment #29) > Created attachment 131869 [details] > complete version of my proposal mentioned above Unfortunately you are a bit late https://design.blog.documentfoundation.org/2017/03/12/survey-standard-palette/. And actually I miss the grey scale.
(In reply to Heiko Tietze from comment #30) > (In reply to tomaskeb from comment #29) > > Created attachment 131869 [details] > > complete version of my proposal mentioned above > > Unfortunately you are a bit late > https://design.blog.documentfoundation.org/2017/03/12/survey-standard- > palette/. And actually I miss the grey scale. I know, but I wanted to address the fact that the saturated colors in the third variant (which seems to be the most popular) don't match the ones with different shades (e.g. there are shades of orange under red). Of course I did not intend to omit the grayscale, it was just a quick mockup that did not include it out of laziness.
Patch is in https://gerrit.libreoffice.org/36202
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=78869ad9d4c904e665529befe5181ea5121fba1d tdf#87538 New standard color palette It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Gabor Kelemen committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fe5b70723fc83f229fb4b41231a663a8700f48c4 tdf#105000, related tdf#87538: Make new color names translatable It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Gabor Kelemen committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6999bafb8675461a7f1400880eabd2daffe96ba4 tdf#105000, related tdf#87538: Make new color names translatable It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=83638a195dfde7255115cac84b2e9bb7e8e1b440 Revert "tdf#105000, related tdf#87538: Make new color names translatable" It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6a0e03bc6c1d6e9f3b66459d82274ecad7f16f58&h=libreoffice-6-0 Revert "tdf#105000, related tdf#87538: Make new color names translatable" It will be available in 6.0.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Yousuf Philips (jay) from comment #0) [...] > I would like to suggest that we crop this list to 8 rows by taking the first > 7 rows and row 12. Also in the first row, we should move the black color to > the right end of the row so the gradient is consistent on that row. I think the most important thing is that the user detects the ordering schema easily. (In reply to V Stuart Foote from comment #4) [...] > I'm not opposed to this. But if the color picker at 12 columns but showing > just 10 rows is a problem, it might be a better option to expand number or > rows, or even columns shown. [...] Why not use a layout of 16x16 (==256) color cells? (In reply to Owen Genat (retired) from comment #6) [...] > - 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 [...] No scrollbar in the color picker, please! That would be inefficient for the user. In general I think the number of colors in a palette is less important than the time the user needs to select the color he/she wants. Di you consider the interesting approach Scribus uses (Create a small set of "logical colors")? See https://wiki.scribus.net/canvas/How_to_create_your_own_colours#The_Colour_Wheel
(In reply to Ulrich Windl from comment #38) > > (In reply to V Stuart Foote from comment #4) > [...] > > I'm not opposed to this. But if the color picker at 12 columns but showing > > just 10 rows is a problem, it might be a better option to expand number or > > rows, or even columns shown. > [...] > Why not use a layout of 16x16 (==256) color cells? > 16x16 would be an odd size to use--and to compose palettes in. See some of the discussions in bug 87538 regards 12x10 with scroll bar appearing beyond 10 rows. And, with the Standard palette now recast (at 6.0, and refined at 6.1) to a generated 12 column RYB color wheel of primaries, secondaries, and tertiaries (Yellow, Red, Blue--Orange, Purple, Green--Gold, Brick--Magenta, Indigo--Teal, Lime) using RGB values--the 12 column UI is positionally significant supporting RYB additive color design. The tonal.soc was also laid out on a 12 column GUI widget. So holding 12 columns makes functional sense. We've kicked around the idea of extending the palette XML (.soc, .sog) to allow it to control its layout in the Color palette widget. But until that gets taken up--a fixed width of 12 columns, with scroll bar when rows exceed 10, is generally sufficient.