(In reply to sergio.callegari from comment #0)
> When trying to modify the color palette of a libreoffice drawing, the
> dialogs are extremely confusing.
> 
> 1) Clicking on the load button, opens a window saying "The list was modified
> without saving. Would you like to save the list now?" - This happens even on
> a just launched LibO, with a just opened document. How can the list be
> already modified in this case?

Hi Sergio,
Please provide a set of steps for us to take to reproduce your problem. If you have a sample document, attaching it to this bug report will help us to triage your bug!

Thank

Status -> NEEDINFO

Hi,

you actually need no sample document. Just do the following

1) start libreoffice with an empty drawing:
   libreoffice --draw

2) draw a shape (any)

3) select it and invoke "Format -> Area"

4) In the format-area dialog, select the "Colors" pane

5) Click on the "Load Color List" button.

you get the "The list was modified without saving. Would you like to save the list now?" alert

This is wrong.

6) Click "OK"

Note that a file *open* dialog appears

This is not coherent with the previous "OK" answer that was given after solicitation to *save* something

7) Select a .soc file and press open

The palette is now updated, confirming that a load action happened

Note that the "embed" tick box is now selected

8) Place the mouse over "embed" tick box

This is bad: there is no help tip for it

9) Press the HELP button

This is bad: the documentation opens, but there is no help for the "embed" tick box

Issue is still present as of 5.1.0.1

I, Bruce Martin, have had a similar problem. Additionally added problems show up that may also be related.

Unable to load/replace colour list from pre-existing standard.soc.

This used to load from the colours window using the Load colour list icon. Now it insists on saving the existing list, and then freezes.

The only ways to unfreeze are to reboot or to kill soffice.bin using the performance monitor.

to restore my ccustom colours, I had to paste a swatch into Gimp, obtain the colour values, then return to Libre Office to re-create the colour from scratch.

If I have to do all this for all colours, gradients and hatches, this amounts to an inordinate mess!

I am using Libre office in Fedora 23 workstation, 64 bit.

Additionally there are a number of colour and choice areas where the mouse does not selct properly asw it used to.

Also the colour bar that used to be available at the bottom of the window simply no longer appears to exist.

I am able to reproduce this issue exactly as described in Comment 2.

Version: 5.1.0.1
Build ID: bcace328aabc4c8c10b56daa87da0a2ee6579b5a
Threads 4; Ver: Linux 3.13; Render: default; 
Locale: en-US (en_US.UTF-8)
Kubuntu 14.04.3 x86_64

Thank you again for bringing this issue to our attention.
I also can confirm the described behaviour.

Windows 10 Pro, Version 1511 (OS Build 10586.36)
Version: 5.0.4.2 Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78
Locale: de-DE (de_DE)

I will set the status to NEW, but lower the importance to LOW/TRIVIAL. While it can be confusing, it doesn't seem to block anyone from using the functions.

Regarding the mentioned freeze and lack of documentation, please consider submitting those issues in dedicated bug reports so we can investigate them independently.

Bug has *significantly* worsened in 5.3

1) It is now impossible to load/save a palette at all in the Format->Area dialog, Colors tab. The functionality has been removed, while it was useful. So we have a regression.

2) The manual still reports the possibility to load a palette via the "Load Color List button" that is no more. Same goes for the possibility to save a palette. The manual reports the possibility to do so via a "Save Color List button" that is no more. So we now also have inconsistent documentation.

3) The same issue, i.e. the inability to load/save lists and the documentation inconsistency seems to be there also for gradients and hatches.

I have risen the priority to "normal" due to these regressions.


Finally, even if this may be a matter of taste, I must say that the whole Format->Area dialog appears to me as generally worsened in 5.3 wrt 5.2.

Particularly, the mutually exclusive Buttons at the top of the color tab (used to select whether an area should be filled with: nothing; a solid color; a gradient; a bitmap; or a hatch) appear as totally inconsistent with other LibO UI elements. To the best of my understanding they are a unicum. This is the sole and only case where textual buttons are used in a dialog to select mutually exclusive options rather than a dropdown.  

As a matter of fact, most UI guidelines, including the Gnome one seems to discourage the use of "toggle buttons" in this way in dialogs. See  https://developer.gnome.org/hig-book/3.10/controls-toggle-buttons.html.en

(In reply to sergio.callegari from comment #9)
> Bug has *significantly* worsened in 5.3

Palette handling has been reworked completely. You do not load a list, which was confusing and not working before, but share palettes via extensions. Read more at https://design.blog.documentfoundation.org/2016/12/30/new-color-palettes-in-libreoffice

=> FIXED

> Finally, even if this may be a matter of taste, I must say that the whole
> Format->Area dialog appears to me as generally worsened in 5.3 wrt 5.2.
> 
> Particularly, the mutually exclusive Buttons at the top of the color tab...

Toggle buttons are indeed a non-conform solution to the issue that we had before. Learn more about the usability engineering at https://design.blog.documentfoundation.org/2015/12/22/area-fill-options-made-consistent/ and how it was realized in http://www.slideshare.net/HeikoTietze/libocon16areafill

Your input is of course very welcome. If you have a good suggestion how we can replace the toggle buttons by a different control except tabs please file it as another enhancement ticket.

> Palette handling has been reworked completely. You do not load a list, which was confusing and not working before, but share palettes via extensions.

I had missed that. Thanks for pointing out.

I understand that the new approach may be easier for those users who can be happy with the default palettes or with palettes they can find ready-packaged as extensions.

However, I feel that the new approach is not exactly friendly for someone who need to set up an "identity" for some casual project (including colors to use) and share it to co-workers, because "normal" users may learn how to edit a palette, or how to load or save it, but certainly not how to edit a soc file and teach others to place it in the correct location, nor to make an extension.

The text "For those who want to share their collections it shouldn’t be too difficult to become familiar with the [extension] format. Extensions are basically ZIP files renamed to OXT. Within the archive the file config.xcu defines the path where the palette has to be placed (no need to change this) and the file description.xml with all information about the extension." (in the linked document) seems a bit too optimistic about the ability to teach users who want to create their own color collections how to share them by creating extensions.

There is still the problem of the documentation, that is inconsistent with the new way of doing things.

For what concerns the toggle button, I think that they should at least be better grouped, now they are so spaced apart that it is hard to realize their toggle function. The mockup looks better in this sense. However, I still feel that a "Fill type" dropdown would be more clear.

(In reply to sergio.callegari from comment #11)
> However, I feel that the new approach is not exactly friendly for someone
> who need to set up an "identity" for some casual project (including colors
> to use) and share it to co-workers, because "normal" users may learn how to
> edit a palette, or how to load or save it, but certainly not how to edit a
> soc file and teach others to place it in the correct location, nor to make
> an extension.

You do not only have the chance to share palettes but also to create own collections via the Custom palette. This one is the replacement for Tools > Options > Colors. And eventually the Document colors should also provide a way to have a unique coloring.
 
> There is still the problem of the documentation, that is inconsistent with
> the new way of doing things.

Fully agreed. Please file a new bug about this.

> For what concerns the toggle button, I think that they should at least be
> better grouped, now they are so spaced apart that it is hard to realize
> their toggle function. The mockup looks better in this sense. However, I
> still feel that a "Fill type" dropdown would be more clear.

Maybe... but keep in mind that we have to scale the dialog for the various themes, screen resolutions etc. and that access to the section is not too difficult.

Hope I'm not abusing of your patience in providing explanations and guidelines. Just two more questions with thanks in advance for the answer!

1) You say:

> You do not only have the chance to share palettes but also to create own collections via the Custom palette. This one is the replacement for Tools > Options > Colors. And eventually the Document colors should also provide a way to have a unique coloring.

can you help me with a best practice workflow?

Suppose that I create a custom palette for some activity. For instance, imagine that I'm in a project with some other people and that we want all the material related to the project to have its own identity, by using certain shapes, colors, etc. To assure the color consistency, I define a custom palette. Now, how do I pass it to the other people in the project? How do I store it for later, assuming that some other activity will require a different custom palette?

2) Apparently, I have a standard.soc, a libreoffice.soc and an html.soc file in my LibO profile (a legacy of previous LibO versions?), which means that I am getting repeated entries in the palette selector. Is this expected?

(In reply to sergio.callegari from comment #13)
> Suppose that I create a custom palette for some activity. For instance,
> imagine that I'm in a project with some other people and that we want all
> the material related to the project to have its own identity...

This use case is supposed to be done per extension. The minimal example is at https://github.com/stbergmann/palette-extension. Click the green "Clone or download" button and select zip. Extract and edit the file palette-extension-master/src/palettes/ by adding/changing the entries <draw:color draw:color="#FF0000" draw:name="My Red"/> (take the RGB value like #FF0000 from the color dialog in LibreOffice or any other tool; the color name can be chosen freely). Once you are finished pack everything from /palette-extension-master/src/ into a zip file (meaning description.xml etc. is on the root) and rename the zip to oxt. This file can be shared- double click in the file browser opens the extension manager. If you want a proper name for your palette just rename the file "My Extension.soc". Everything is also explained in the blog post.

> 2) Apparently, I have a standard.soc, a libreoffice.soc and an html.soc file
> in my LibO profile (a legacy of previous LibO versions?), which means that I
> am getting repeated entries in the palette selector. Is this expected?

You wont get repeated entries if palette names are different. html.soc is the web standard of color with well-defined names, standard.soc what we use by default (this palette is being updated again right now) and libreoffice.soc the branding colors as defined by design and marketing.

> This use case is supposed to be done per extension. The minimal example is at https://github.com/stbergmann/palette-extension. Click the green "Clone or download" button and select zip. Extract and edit the file palette-extension-master/src/palettes/ by adding/changing the entries <draw:color draw:color="#FF0000" draw:name="My Red"/> (take the RGB value like #FF0000 from the color dialog in LibreOffice or any other tool; the color name can be chosen freely). Once you are finished pack everything from /palette-extension-master/src/ into a zip file (meaning description.xml etc. is on the root) and rename the zip to oxt. This file can be shared- double click in the file browser opens the extension manager. If you want a proper name for your palette just rename the file "My Extension.soc". Everything is also explained in the blog post.

Saw it, but looks too difficult to be proposed to non expert users. Hoped in something easier. Do you think that it could make sense to propose, as an enhancement request, some functionality to automatically convert the current "custom palette" in an extension containing the corresponding soc file? Possibly, functionalities for the management of palette extensions could be implemented in a dedicated extension itself...

> You wont get repeated entries if palette names are different. html.soc is the web standard of color with well-defined names, standard.soc what we use by default (this palette is being updated again right now) and libreoffice.soc the branding colors as defined by design and marketing.

Yes, I was expecting something like this, but I was wondering why I had these soc files in my profile in the first place...

Thank you very much for all the help and sorry if I sort of abused the bug tracker...

(In reply to sergio.callegari from comment #15)
> Saw it, but looks too difficult to be proposed to non expert users. Hoped in
> something easier. Do you think that it could make sense to propose, as an
> enhancement request, some functionality to automatically convert the current
> "custom palette" in an extension containing the corresponding soc file?
> Possibly, functionalities for the management of palette extensions could be
> implemented in a dedicated extension itself...

I would vote against such a function. LibreOffice is not a tool to manipulate palettes, let's keep it simple. Your use case is very special. And users who share palettes are likely on an admin level and should be able to deal with the extension. Actually I don't see the problem for average users to edit an XML file and pack it into a zip.
However, if an extension provides the functionality to export the custom palette   as an extension that would be very welcome.

Heiko, just IMHO: The LibreOffice vision is "Simple for beginners and powerful for experts". Therefore it's a pity that palettes only can be shared with extensions from now. I hope you don't copy the Mozilla desease to cut special features step by step, unifying it by something more complicated or less powerful. Because special users are the most faithful one for projects like LibreOffice. (Learning making extensions is an additional effort only for bringing e.g. a company color palette to other users.)

Here is an extension that allows to easily export the custom palette [1] and a blog post [2] with some background information.

[1] https://extensions.libreoffice.org/extensions/custom-palette-eport
[2] https://design.blog.documentfoundation.org/2017/03/29/libreoffice-extension-export-custom-palette/

Excellent news, thanks! I'll test it asap.