The new area fill options make it possible to add new colors, gradients, bitmaps, patterns and hatches. But after adding, it's not possible to rename it. You can only delete and re-add it but that's not user-friendly for example if you have added it in a sorted manner and deleting + re-adding would destroy that order. Steps to reproduce: - Open a Writer document. - Go to Format > Paragraph > Area > Color - Add a new color to the custom palette and enter a name. Actual result: There is no way to rename the color. (This also occurs for gradients, bitmaps, patterns and hatches.) Expected result: A rename button could be added beside the existing Add/Delete/Modify buttons. (LibO version 5.3.0.3)
Definitely not as a button, that's a recipe for featuritis, but as a context menu. And we do have this function there, check the other sections such as gradients; everywhere except for solid colors. So yes, please add a function to rename custom colors. The solid color section is a bit different to the other area fill options. During the design phase we talked about that and decided in the end to accept this inconsistency. And alternative solution could have been to show Add/Modify like everywhere else and to put the color name in an edit field that is enabled for custom colors only. Smells like an easyhack, right?
Indeed, I missed the fact that in all others but the color tab a context menu exists that enables renaming and deleting of entries. Wouldn't it be the easiest way to copy the button + contest menu design of Gradient/Bitmap/Pattern/Hatch tab to the Color tab - or do users more delete than modify colors in comparison to the other tabs? What's the advantage of the actual color tab design? Personally (without any UX data) I would prefer to show Add/Modify in color tab like everywhere else and to put renaming and deleting to the context menu that is enabled for custom colors only.
Created attachment 143816 [details] Libreoffice colors Palette Drop-Down
Libreoffice Version 6.0.5.2 I look forward to the ability to rename a color profile in Libreoffice via the GUI. Currently I just rename the file. Under linux the .soc file is located: $HOME/.config/libreoffice/4/user/config/ Libreoffice then creates a .pack file with the same base name under: $HOME/.config/libreoffice/4/user/pack/config/ However, I think the palettes installed as extensions are located under: $HOME/.config/libreoffice/4/user/uno_packages/cache/uno_packages/ In addition to a Modify/Rename option, it would be helpful if the palette names in the Colors Palette drop-down were sorted. Currently there doesn't appear to be any sort order to the items in the list. After reading the two blog enters below, I reviewed my color palettes and associated files. I have some files in my local directory with the same name as those on the shared system, and I wondered how that worked. Both entries, with the same name, appear in the drop-down, but in different locations in the list. The contents of some of the files are different, and for now I thought I would just rename the local files with a prefix until I have a better understanding. 1. https://design.blog.documentfoundation.org/2017/04/10/new-standard-color-palette/ 2. https://design.blog.documentfoundation.org/2016/12/30/new-color-palettes-in-libreoffice/
Finding, in LibreOffice 6 on Linux, that custom palettes are no longer read from ... ~/.config/libreoffice/4/user/template ... I have had to resort to using administrator privileges to place my .soc file at ... /usr/lib/libreoffice/share/palette This works for me, on a Linux desktop for myself. I am unsure how I'm going to deal with colleagues (on Windows or Mac desktops), when I send them an Impress presentation for editing). I guess they'll be restricted to the "Recent colors" that I've appended at the bottom of standard.soc .
(In reply to daviding from comment #5) > ... I am unsure how I'm going > to deal with colleagues (on Windows or Mac desktops), when I send them an > Impress presentation for editing). I guess they'll be restricted to the > "Recent colors" that I've appended at the bottom of standard.soc . You can install palettes as an extension. And use my extension [1] to export the custom colors as that. Also, there would be the "Document colors" palette (but as reported in bug 84577 not working). IIRC, palettes are sorted now alphabetically in 6.2. [1] https://extensions.libreoffice.org/extensions/custom-palette-eport
(In reply to V Stuart Foote from comment #6) > OK, so question becomes how to rename. Efficient way would be to extend the > color swatches when exposed in an active Palette tool instance. And from > there provide some context menu actions against the swatch object: > > 1). add to Custom palette > 2). name/rename color swatch (as held in Custom and/or Document palette) > 3). adjust color (to launch 'Pick a Color' dialog) > > The swatch attributes would be exposed from any active Palette tool > instance, but 'rename' or 'adjust' would only apply when accessed from the > Custom or Document palette. Don't understand your ideas. We could simply show the naming dialog again after double click or per context menu (IIRC this was part of the original proposal).
*** Bug 127468 has been marked as a duplicate of this bug. ***
(In reply to Heiko Tietze from comment #7) > Don't understand your ideas. We could simply show the naming dialog again > after double click or per context menu (IIRC this was part of the original > proposal). It is not that the Area tool's functions don't need changes as in OP, it is more that it is too limited in scope for what should be available across the GUI. Enhancement of the palette tool and color picker would provide direct color work flows to the entire GUI. Not the awkward means now of having to make color changes in the Area dialog, to only then pick up via the Custom palette. Gist of it is that the context menu actions would be against the swatches held in the color Palette dialogs and _not_ dependent on the 'Area' dialog at all. So accessible from any object calling a color value--e.g. draw objects, text, lines, borders, etc. But, just user's profile color swatches held in the Recent bar, or held in the Custom or Document palette--swatches from other palettes would only be "add to custom" (and so into user profile) and from there exposed to name/rename/modify. We'd have to do it that way to maintain integrity of the LO system paletts. Only work against colors and their swatches as held in user profile. Any color modification done would be with the "Custom color" 'Pick a color' dialog. These changes to the palette & swatches coupled with RFE of bug 124418 would round out color handling, including the palette tool integrated into the 'Color' tab of the Area dialog. Export of Custom palette or Document palette to a new .SOC (either via extension, or restore feature to the GUI) is another issue. As is import of additional pallet formats (possibly including CMYK and CIE-Lab color conversions).
RFE ion this ticket is to rename the stored user color. And I don't see a problem UX-wise for the latter. Let's discuss the other aspects and more controversial topics in bug 124418.