Since LibreOffice 4.4 and 5.0, it is possible to import/load .gpl and .ase color palettes. However, there is no UI for this, so that the user needs to manually copy the color palettes into the correct folder (see [1]). It seems to be very easy to add this to the existing Tools -> Options -> Colors -> Load Color List option, which currently can only load *.soc color palettes. Enhancement request: Please add .ase and .gpl also to the "Load Color List" option. Thanks. [1] http://ask.libreoffice.org/en/question/46259/how-can-i-import-gimp-palette/
Thanks Gerry!
About ase palette, it should be ok from 5.0.0 according to tdf#84002 except lab colors, see http://cgit.freedesktop.org/libreoffice/core/commit/?id=797c48f0f74501def9f47444538c0e110fcfcca1 About gpl palette, I saw codepointer here: http://opengrok.libreoffice.org/xref/core/svx/source/tbxctrls/Palette.cxx#170 However, indeed only "soc" is proposed when using Tools -> Options -> Colors -> Load Color List option Chris/Tomaz: thought you might be interested in this one.
(In reply to Julien Nabet from comment #2) > Chris/Tomaz: thought you might be interested in this one. Thanks Julien, I'll take a look!
I just noticed this too, when trying to test the .ase loading feature developed by Chris. Great to see you're looking into this!
Yes, the Options->Colors page doesn't support palettes at all. It would be nice to modify the dialog so that you can browse the available palettes and modify the colors (same as it is done now for standard palette) and add (copy into LO config folder) new palettes from an arbitrary location. The issue is however what to do when the ase or gpl palette is modified as we don't support saving for this two formats. I guess we can only allow saving when the palette is soc (for now). I don't think users will be doing this very often or at all. Chris, great if you have time to work on this!
(In reply to Tomaz Vajngerl from comment #5) > Chris, great if you have time to work on this! No guarantees but I'll try to take a look :)
Migrating Whiteboard tags to Keywords: (needsDevEval) [NinjaEdit]
(In reply to Tomaz Vajngerl from comment #5) > The issue is however what to do when the ase or gpl palette is modified as > we don't support saving for this two formats. I guess we can only allow > saving when the palette is soc (for now). I don't think users will be doing > this very often or at all. I'm not familiar with the code (nor with palette, so please excuse me if this is dumb), but in case the palette is imported (loaded to memory) into native format, isn't that natural when loading from arbitrary location to browse for a .ase/.gpl, then save its copy to LO config folder as .soc right away?
Adobe Swatch Files (.ASE) were requested again here https://design.blog.documentfoundation.org/2016/12/30/new-color-palettes-in-libreoffice/#comment-1881
Created attachment 141033 [details] palette colors file easy to edit <hidden but real comment> What's the hell ? just imagine, you've a society, you create a design colors for web/card/document and a nice tool help you in Libreoffice 5... then you migrate to LO6 and *oops* forget your corporate colors, LO6 have the only right colors ! Hey, are you regressing ? should I learn XML code to edit my colors ? what next ? LATEX ? HTML5 ? get back to Microsoft Office ? </hidden but real comment> If you already have a .soc file, you could import it by copying it here : C:\Users\XXX\AppData\Roaming\LibreOffice\4\user\config (where XXX is you login)
(In reply to roumanet from comment #10) @roumanet : I agree that it would be nice to have a UI to import/load/edit .gpl and .ase color palettes in LibreOffice. However, you seem a bit too angry. Yelling or using swearwords aren't really helpful, nowhere and particularly not in an open source project. @LibreOffice developers: In this bug entry, there is still the keyword "needsDevEval". Could anyone please have a look at this enhancement, whether it qualifies for an EasyHack? Thanks.
Sorry Gerry, you're right. Probably because my english isn't good enough to let me express precisely (or should I use Google translate ?) However, I'm a bit angry because I see more and more bugs impacting my life (I'm teacher and I work all my documents with LO only, even if I have MO 2016 for a small amount of money -- thanks to Microsoft partnership with education). I've created some tickets (like you on this one) few years ago... But you're right, my sentences could hurt some coders : I felt like an hostage when something was working and then is removed.
In my opinion we should not add controls to load foreign palettes. It spoils simplicity and makes the dialog less easy to use. You might answer one button is not a big deal but there are several requests to seldom used features that end up in very complex dialogs. So my recommendation is to put the palette into an extension in order to load it (haven't tested if ase/gpl is recognized directly). Some tips how to create the extension are here https://design.blog.documentfoundation.org/2017/03/29/libreoffice-extension-export-custom-palette/ => WFM (up to QA)
IMO still a valid idea.and it would be hard to prevent someone to write core-code because it can be done in an extension too? Anyway, useful blog pointing to the Extensions too: https://design.blog.documentfoundation.org/2016/12/30/new-color-palettes-in-libreoffice/
Curiously there is code to load ase/gpl: https://opengrok.libreoffice.org/xref/core/svx/source/tbxctrls/Palette.cxx => PaletteASE() and PaletteGPL()# So maybe it's fixed anyway (haven't tried to load those formats).
The ability to load palettes from the UI was intentionally removed [1]. The supposed way to do is per extension, which works perfectly even with GPL and ASE. => WFM [1] https://design.blog.documentfoundation.org/2016/12/30/new-color-palettes-in-libreoffice/ (and other posts)
(In reply to Heiko Tietze from comment #16) > The ability to load palettes from the UI was intentionally removed [1]. The > supposed way to do is per extension, which works perfectly even with GPL and > ASE. => WFM heh, the blog post doesn't mention the explicit decision; and also one of its comments was answered by you back then with the link here - so could you please point to the decision, or describe its rationale here briefly?
(In reply to Mike Kaganski from comment #17) > ...so could you please point to the decision, or describe its rationale here briefly? There are many post on that topic. The search function helps you to find it. Rationale was that palette loading is a very rarely needed feature and if only for the admin persona (normal user don't share palettes). Therefore we dropped the loading capabilities. But I uploaded an extension to our site that makes saving the user palette very easy.