Bug 106817 - Custom color palettes as extension can't be edited
Summary: Custom color palettes as extension can't be edited
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Color-Palettes
  Show dependency treegraph
 
Reported: 2017-03-28 11:46 UTC by Thomas Lendo
Modified: 2021-09-02 08:18 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Lendo 2017-03-28 11:46:12 UTC
Since 5.3 the area fill tool and color palettes were overhauled completely. Now custom color palettes can be exported as extension so that anybody else can import it (https://extensions.libreoffice.org/extensions/custom-palette-eport). -- See also bug 90631, comment 10 ff.

But only the original palette creator can edit the colors within his/her custom palette. Palettes imported as extensions can't be edited (and maybe re-exported) like LibO standard palettes can't because they are outside the custom palette.

This is a severe restriction in an environment where more than one should be able to edit a color palette. Or maybe the creator's computer is damaged and the palette only exists as extension.

Suggestion 1:

Imported palettes should be handled like the custom palette with means to modify, remove and rename colors.

Suggestion 2:

It should be possible to pick the custom color palette file and imported color palette files within a file manager in the user profile to copy, to edit it by hand or to rename it.
(For example: A imported palette will be renamed so that LibO assumes it is the custom palette. Then it can be edited in the custom palette and re-exported or copied or whatever. -- Where are custom and imported color palettes stored now to edit or copy them in an company environment without extension system?
Comment 1 Heiko Tietze 2017-04-02 10:31:32 UTC
(In reply to Thomas Lendo from comment #0)
> Suggestion 1:
> 
> Imported palettes should be handled like the custom palette with means to
> modify, remove and rename colors.

You would need to override the previous custom colors or to merge the two lists. Both likely not wanted.
 
> Suggestion 2:
> 
> It should be possible to pick the custom color palette file and imported
> color palette files within a file manager in the user profile to copy, to
> edit it by hand or to rename it.

Don't get it, and it sounds strange.

The enhancement request is a clear WONTFIX for me. Color palettes are one mean to handle a list of colors. You still have the document colors, the ordinary color picker, own custom colors etc. 
There is no use case to make palette handling as easy as possible, and when we add more options here it's feature-creep. Even the (IMHO more obvious) solution #3, to define at the palette itself whether it is read-only or not, makes no sense as it adds complexity (it's not the checkbox, or the like, that is complex but all reasoning behind we do in this and other tickets that average users are not aware of). People who want to go into detail should rather hack the file.

> Where are custom and imported color palettes stored now...

Predefined palettes are placed at <LibO>/share/palette, the user palettes in <user>/libreoffice/4/user/extensions/+, the custom palette is stored in <user>/libreoffice/4/user/registrymodifications.xcu.
Comment 2 Thomas Lendo 2017-04-03 08:56:33 UTC
(In reply to Heiko Tietze from comment #1)
> (In reply to Thomas Lendo from comment #0)
> > Suggestion 1:
> > Imported palettes should be handled like the custom palette with means to
> > modify, remove and rename colors.
> 
> You would need to override the previous custom colors or to merge the two
> lists. Both likely not wanted.
Accepted if not wanted. But I mean neither an override nor a merge. Imported palettes should be handled like custom palettes but should still be separate palettes. (Don't know how the palette management is implemented now, in a user's POV it only needs a "edit-possible" or "handled-like-custom" flag set to the imported palettes. :-) ) Example:

------------------------------
| imported palette           |   <--- edit possible
| imported palette           |   <--- edit possible
| custom palette             |   <--- edit possible
| LibO breeze palette        |   <--- no edit possible
| LibO xyz palette           |   <--- no edit possible
| LibO standard palette      |   <--- no edit possible
------------------------------

With that others can also improve/edit palettes and it's not stuck(!) to the first and original editor and export user of the palette.
(Use case if user edits the imported palette unwantedly: 1) Users fear changes, so this isn't a problem that I see. 2) If a user did a change, it can be undone by re-importing the extension palette easily.)

> > Suggestion 2:
> > It should be possible to pick the custom color palette file and imported
> > color palette files within a file manager in the user profile to copy, to
> > edit it by hand or to rename it.
> 
> Don't get it, and it sounds strange.
What I meant is if the custom palette were saved as a separate .soc file in the user's profile, you could take the imported extension palette .soc file from user\uno_packages\cache\uno_packages\lu123 and you could copy that file to the place where the custom palette would be saved. Then you could rename both so that the new .soc file (and not the original custom palette .soc file) is handled like the custom palette in LibreOffice.

But as you said, the custom palette is now part of the registrymodifications.xcu (and no separate .soc file anymore) which makes it extraordinarily difficult to handle this use case.

> There is no use case to make palette handling as easy as possible, and when
> we add more options here it's feature-creep. Even the (IMHO more obvious)
> solution #3, to define at the palette itself whether it is read-only or not,
> makes no sense as it adds complexity (it's not the checkbox, or the like,
> that is complex but all reasoning behind we do in this and other tickets
> that average users are not aware of). People who want to go into detail
> should rather hack the file.
I explained the use case above and in the initial bug comment.
I don't want any new options. The user should have nothing to do. It should just be possible to edit imported palettes like custom palettes. Maybe if it's not wanted then a flag in the Expert Configuration could be set.
Comment 3 QA Administrators 2019-09-02 09:23:09 UTC Comment hidden (obsolete)
Comment 4 Thomas Lendo 2019-09-02 10:51:49 UTC
Nothing changed.
Version: 6.4.0.0.alpha0+ (x64)
Build-ID: 41cd3e8e817c8c33a13608e62eeb06ce2c6977e4
CPU-Threads: 12; BS: Windows 10.0; UI-Render: GL; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-09-01_22:04:10
Gebietsschema: de-AT (de_AT); UI-Sprache: de-DE
Comment 5 QA Administrators 2021-09-02 03:51:44 UTC Comment hidden (obsolete)
Comment 6 Heiko Tietze 2021-09-02 08:18:42 UTC
Imported palettes are like templates or gallery items some static piece of artwork. There is no point of editing the Breeze colors, for example, and if it belongs to the maintainer. So clearly a NAB (actually WF) to me.