Allow extensions to provide color palettes

See below master commit for details.  If there's no concerns, I'll 
backport that commit to libreoffice-5-3 in the coming days.  Might be a 
solution for 
<https://bugs.documentfoundation.org/show_bug.cgi?id=104052> "Add 
LibreColour HLC palette".

On 11/29/2016 03:36 PM, Stephan Bergmann wrote:
> commit e2ea7bb3a6b681822a247e8c277694f921c92273
> Author: Stephan Bergmann <sbergman@redhat.com>
> Date:   Tue Nov 29 15:01:21 2016 +0100
>
>     Allow extensions to provide color palettes
>
>     Until now, .oxt extensions cannot provide additional color palettes (.soc files,
>     see e.g. Draw's "Format - Area... - Area - Color - Colors - Palette:" drop-down
>     list).  There are two ways how this feature could be added:
>
>     Either add a new file-entry media-type to extensions' META-INF/manifest.xml and
>     add support for that in the code.
>
>     Or leverage the existing code, which reads the configuration set
>     /org.openoffice.Office.Paths/Paths/Palette/InternalPaths, where each set element
>     denotes a directory, and scans those directories for .soc files.  So an
>     extension would include an .xcu file adding such a path (using %origin% to
>     denote a directory within the .oxt file itself) and a directory with one or more
>     .soc files.
>
>     For simplicity, this commit uses the second way.  The only problem with the
>     existing code is that extension configuration data using %origin% is rewritten
>     to vnd.sun.star.expand URIs which the palette-scanning code does not support.
>     So extend SvtPathOptions_Impl::GetPath's PATH_PALETTE case to expand such URIs.
>     (The choice of doing it in SvtPathOptions is somewhat arbitrary; there would be
>     other, more generic places where it might make sense to do such expansion, but
>     which would also carry a higher risk of regressions.)
>
>     <https://github.com/stbergmann/palette-extension> contains an example of such an
>     extension (with a LibreOffice-minimal-version of "LibreOffice 5.3", assuming
>     this commit will be backported to upcoming LO 5.3).
>
>     Some drawbacks of going this way are:
>
>     * No control over where extension palettes appear in the palette drop-down
>       lists.  (But those lists appear to be sorted in some random order, anyway?)
>
>     * Commit on future support of the .soc file format (which, however, is XML) and
>       the /org.openoffice.Office.Paths/Paths/Palette/InternalPaths configuration set
>       in a backward-compatible way.  (But any other way of implementing this feature
>       would also need a similar commitment.)
>
>     * Somewhat odd, indirect approach where an extension specifies a directory
>       filled with .soc files, instead of specifying the .soc files diretly.
>
>     * With the current palette-management code, live extension addition/removal is
>       not immediately reflected in all places that offer palette drop-down lists.
>       (But this should be fixable, and would be an issue with other approaches,
>       too.)
>
>     Change-Id: I68b30127d61764d1b5349f1f2af9c712828bee3e
>
> diff --git a/unotools/source/config/pathoptions.cxx b/unotools/source/config/pathoptions.cxx
> index 7b64c91..d905245 100644
> --- a/unotools/source/config/pathoptions.cxx
> +++ b/unotools/source/config/pathoptions.cxx
> @@ -32,6 +32,7 @@
>  #include <unotools/bootstrap.hxx>
>
>  #include <unotools/ucbhelper.hxx>
> +#include <comphelper/getexpandeduri.hxx>
>  #include <comphelper/processfactory.hxx>
>  #include <com/sun/star/beans/XFastPropertySet.hpp>
>  #include <com/sun/star/beans/XPropertySet.hpp>
> @@ -237,6 +238,22 @@ const OUString& SvtPathOptions_Impl::GetPath( SvtPathOptions::Paths ePath )
>              osl::FileBase::getSystemPathFromFileURL( aPathValue, aResult );
>              aPathValue = aResult;
>          }
> +        else if (ePath == SvtPathOptions::PATH_PALETTE)
> +        {
> +            auto ctx = comphelper::getProcessComponentContext();
> +            OUStringBuffer buf;
> +            for (sal_Int32 i = 0;;)
> +            {
> +                buf.append(
> +                    comphelper::getExpandedUri(
> +                        ctx, aPathValue.getToken(0, ';', i)));
> +                if (i == -1) {
> +                    break;
> +                }
> +                buf.append(';');
> +            }
> +            aPathValue = buf.makeStringAndClear();
> +        }
>
>          m_aPathArray[ ePath ] = aPathValue;
>          return m_aPathArray[ ePath ];