unotools/source/config/pathoptions.cxx |   17 +++++++++++++++++
 1 file changed, 17 insertions(+)

New commits:
commit 7f9338f4b8dc1e112d4268868bcc651764969645
Author: Stephan Bergmann <>
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 
    see e.g. Draw's "Format - Area... - Area - Color - Colors - Palette:" 
    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 
    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 
    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 
    .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 
    to URIs which the palette-scanning code does not 
    So extend SvtPathOptions_Impl::GetPath's PATH_PALETTE case to expand such 
    (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, 
    which would also carry a higher risk of regressions.)
    <> 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, 
    * Commit on future support of the .soc file format (which, however, is XML) 
      the /org.openoffice.Office.Paths/Paths/Palette/InternalPaths 
configuration set
      in a backward-compatible way.  (But any other way of implementing this 
      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 
      not immediately reflected in all places that offer palette drop-down 
      (But this should be fixable, and would be an issue with other approaches,
    Change-Id: I68b30127d61764d1b5349f1f2af9c712828bee3e
    (cherry picked from commit e2ea7bb3a6b681822a247e8c277694f921c92273)
    Tested-by: Jenkins <>
    Reviewed-by: Caolán McNamara <>
    Tested-by: Caolán McNamara <>

diff --git a/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 ];
Libreoffice-commits mailing list

Reply via email to