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 <[email protected]>
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 ];
_______________________________________________
LibreOffice mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
