https://bugs.documentfoundation.org/show_bug.cgi?id=106817
Thomas Lendo <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #2 from Thomas Lendo <[email protected]> ---
(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.
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
