Draw an object, RMB > Area > Color I want to delete a given custom color, but the button 'Delete' is inactive anymore. Worked fine for years, but we used 4.1.4 version in the company for a long time, only recently we have updated.
On pc Debian x86-64 with master sources updated today, I don't reproduce this. I noticed that when creating a custom color, it was in registrymodifications.xcu, a file which belongs to LO profile. For the test, could you rename your LO directory profile (see https://wiki.documentfoundation.org/UserProfile#Windows) and give a new try?
(In reply to Julien Nabet from comment #1) > On pc Debian x86-64 with master sources updated today, I don't reproduce > this. > > I noticed that when creating a custom color, it was in > registrymodifications.xcu, a file which belongs to LO profile. > > For the test, could you rename your LO directory profile (see > https://wiki.documentfoundation.org/UserProfile#Windows) and give a new try? Hello, I did, and I can remove custom colors, but simply I was surprised these are not in .soc palettes in /config anymore, as we have custom company's palettes. So the problem now is when I use a custom .soc palette I cannot delete the color. Currently, custom colors are written in registrymodifications.xcu, and in values unrecognizable. What is needed then is to restore to ability to fully edit custom .soc palettes. Sorry, I was not clear about that, simply, I could not imagine someone would got the idea to remove this extremely clear and versatile way of writing down different, many custom palettes.
[Automated Action] NeedInfo-To-Unconfirmed
Cannot confirm neither with 6.3.6.2 nor 7.0. Have you clicked the custom color entry? The frame for currently active colors might be confusing.
Created attachment 160809 [details] Inactive delete button
(In reply to Heiko Tietze from comment #4) > Cannot confirm neither with 6.3.6.2 nor 7.0. Have you clicked the custom > color entry? The frame for currently active colors might be confusing. Hello Heiko, Please see the attachment. Custom color marked, standard.soc palette, inactive Delete button. Cheers, Piotr
(In reply to Piotr from comment #6) > Custom color marked, standard.soc palette, inactive Delete button. That's by design, you cannot delete entries from the bundled palettes. Only the user defined colors can be deleted. Reason is that normal users likely don't have write access where those information is stored, while the user colors are located at the user space. To clarify the situation I think we should add a tooltip when the button is disabled.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c895a6d8298a349784cd0aafff4bf518ac8d0a7d Resolves tdf#132799 - Deleting of colors unclear It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #9) > Heiko Tietze committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > c895a6d8298a349784cd0aafff4bf518ac8d0a7d > > Resolves tdf#132799 - Deleting of colors unclear > > It will be available in 7.0.0. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback. Hello Heiko, Thank you for proceeding. Actually, on Windows 8.x and 10 all this information is stored in the same place, \user folder. Bundled palettes are in the subfolder, so a user has the access to all of it. I would make a kind separate request to restore the functionality of writing down user's palettes in .soc files, as this is the only way to manage several different custom palettes for several separate groups of workers in a company. If all custom palettes are in registrymodification.xcu only, than all people have to use same .xcu file to have access to them. Despite, the colors are in a strange format, not in html anymore. Anyway, once again, thank you so much for making the effort. Cheers, Piotr