- do not use gb_UnpackedTarball_copy_header_files for boost
- adapt the optimization in concat-deps.c for new path
- use boost_headers in all LinkTargets that require it
- add explicit include paths to mysqlc, mysqlcppconn, libvisio, liborcus
Change-Id: I0c43e73ed43cc9d2e6bce8faf55e992d655a0bb9
Apparently the login() method in Python 3.3 expects str arguments for
user and password, since it calls encode on them, but for Python 2.6 the
"encode" calls were explicitly added in the caller since login() does
not encode itself; add an ugly version check for that.
Change-Id: Iebfce44073a837e9cb845855ba448d5b6a2ebd11
as the corresponding test is otherwise seen to fail, with user being b, but I have
no idea if this is the most Python-3-ish approach to fix that, or whether more code
needs to be fixed, too.
Change-Id: Ia7fbcbca3cf578ffe1bd5ce3c7c5b709cc77317e
I had to drop XEventBroadcaster from the merged interface
because it introduced method name conflicts (addEventListener).
Shouldn't be an issue since it was scheduled to be dropped anyhow,
and the service implementation still implements it, so existing clients
will be fine.
I dropped the interface XPropertySet from the combined IDL because nobody
seems to be using it, and it's primary purpose appears to be to set weird
flags.
I dropped the optional interfaces
XStatusIndicatorFactory
XDispatchInformationProvider
from the combined IDL because the service does not implement them, and
nobody seems to be using them. I suspect they were mistakenly copied
from XFrame.
I also did not convert the Title, UserDefinedAttributes and LayoutManager
properties to attributes, again because no-one is using them.
Change-Id: I678a00006ed2cca2d6c37c4e39465811442c33af
This changes all generated API headers (.hpp and .hdl) to use a
namespace alias 'css' instead of the pointlessly long com::sun::star
Makes the change in cppumaker & associated tools, adds a global
namespace alias definition in sal/types.h, and removes a kiloton
of local, now pointless-to-harmful versions of that alias from all
over the code.
Change-Id: Ice5a644a6b971a981f01dc0589d48f5add31cc0f
To avoid unnecessary confusion between the newly plain code and any instance of
the old extension still installed (per-user or shared), I renamed the UNO
implementation identifier org.openoffice.pyuno.LanguageScriptProviderForPython
to org.libreoffice.pyuno.LanguageScriptProviderForPython. Also, existing
installations of the extension are explicitly not migrated to new user profiles.
Change-Id: Id3dd66ba5e52e0962f7ad0ccb5e4ad5b0bec97fa
The service is deprecated, but we still have a handful of in-tree
users, and converting it lets me thread XComponentContext through
a bunch of classes.
Change-Id: Iffdfe537ada6b9e4a89f9b3c8dd82ca85f4bfaba
Added two new writer commands: NextTrackedChange (FN_REDLINE_NEXT_CHANGE) and
PreviousTrackedChange (FN_REDLINE_PREV_CHANGE).
Rewrote the logic for Accept/Reject change (FN_REDLINE_ACCEPT_DIRECT and
FN_REDLINE_REJECT_DIRECT) to work well with the newly introduced commands.
Change-Id: I03d583bef4225409f69934f16db1854564c2db5f
Reviewed-on: https://gerrit.libreoffice.org/1156
Reviewed-by: Bosdonnat Cedric <cedric.bosdonnat@free.fr>
Tested-by: Bosdonnat Cedric <cedric.bosdonnat@free.fr>
... derives from com.sun.star.uno.RuntimeException instead of
com.sun.star.uno.Exception.
Only test that breaks with this change is jurt_uno/AnyConverter_Test,
which for mysterious reasons effectively tests that
IllegalArgumentException is a subclass of Exception and not
RuntimeException. Presumably this is just a generic exception test that
happens to use IllegalArgumentException.
Some further testing indicates there are no problems expected at
runtime:
Running "make subsequentcheck" with all Java test code compiled against
a ridl.jar that does not contain the change, running against a soffice
that uses ridl.jar and rdbs with the change + ridl.jar with the change
on the test side yields exactly the same AnyConverter_Test failure, with
no other failures.
Change-Id: Iad183de76ec7e0d56648084e97cdcc160b5b033d
I upgraded the service to return XSimpleFileAccess3, since it
already implemented that interface, and it's backwards
compatible.
Change-Id: I40001a46048bd21a23b6a2f58a95376f06fc634b
This reverts commit dd6c4f4db1 "fdo#46102: Load
Java scripts with class loaders that actually find them." That commit broke
support for macros embedded in documents (as
new java.net.URL("vnd.sun.star.tdoc:...") throws a MalformedURLExcetpion), and
it looks like that commit was not necessary after all -- or rather that what it
tried to work around must have been some other problem that has been fixed
meanwhile. "It is unclear to me how the Java script provider shall ever have
found the script jars in the past" indicates that something must have been
fishy, and what I failed to notice back then is that createURL creates
java.net.URL instances with a UCBStreamHandler that does allow to obtain content
from weird-looking URLs.
Anyway, with that reverted, all three following scenarios work on both current
master (towards LO 3.7) and libreoffice-3-6 (towards LO 3.6.4); I haven't yet
come around to test on libreoffice-3-5:
1 Stock macros, "Tools - Macros - Run Macro... - LibreOffice Macros -
HelloWorld", running all of the four "helloworld.bsh", "helloworld.js",
"HelloWorldPyhton", and
"org.libreoffice.example.java_scripts.HelloWorld.printHW".
2 Per-document macros, loading test.odt attached to fdo#49517, then "Tools -
Macros - Run Macro... - test.odt - HelloWorld", running
"org.libreoffice.example.java_scripts.HelloWorld.printHW".
3 Extension macros, installing ScriptDispatch.oxt attached to fdo#46012 as
shared extension, then loading StartScriptDispatch.odt attached to fdo#46012 and
pressing the "Start Java via ScriptProvider" button.
Change-Id: I31cd16b3720ffeb1058722d4d1fdffb773f8a067
Create a merged XToolkit2 interface for this service to implement.
Which is backwards-compatible, but does not require creating a new service.
Also mark sub-interfaces as non-optional.
Change-Id: I278d0288e92be277033013302267cf93f7d70480
One of the javascript examples parcel-descriptor.xml ended up with a c++
comment instead of a xml comment
Change-Id: Ie63a30e19de2caae08e9a489b6592e1046037416
