The arguments for a macro when invoked by the dispatch provider get
converted from a set of PropertyValues to a sequence of Anys containing
just the values. Since the commit below, the TransformItems step was
changed to store the PropertyValues in an unordered_map which makes the
order of the values unpredictable. If the dispatch provider is used to
execute a macro then the order of the arguments becomes important
because the macro has no other way to determine which argument
represents which property. In order to maintain the previous behaviour,
the dispatch method now reorders the arguments so that they have the
same order as before. The previous order was determined by the order the
properties were handled in TransformItems.
commit e8d73d5307
Author: Mike Kaganski <mike.kaganski@collabora.com>
Date: Wed Dec 3 10:45:35 2025 +0500
Let TransformItems return comphelper::SequenceAsHashMap
Simplifies its usage in all places where the result needs to be
modified.
Change-Id: I37f8d99827e0f1cb2b6e4f4f7735e26fb87f6703
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195162
Change-Id: Iacf64650842eb62c0a2bd266784aa9c7accf45bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209231
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
The commit below changed the unit test so that if the QuickJS provider
isn’t available then the entire test is skipped. Even if the provider is
available, it also changed the check condition so that the test is
skipped if the dummy JavaScript macro was not found. This makes creating
the dummy macro a bit pointless.
The idea of the test is to make sure that all of the script providers
return nodes that can be handled from Python. If the QuickJS provider
isn’t available then it’s still interesting to test the other providers.
If it is available then we want to make sure the dummy script is found
otherwise the test won’t be checking that the nodes returned by the
singleprov code can be handled by Python.
This patch changes the logic so that it will continue the test even if
the QuickJS provider isn’t built but in that case it will skip the
assert that the dummy macro is found.
commit feddb7e827
Author: Christopher Sherlock <chris.sherlock79@gmail.com>
Date: Sat Jul 25 17:17:33 2026 +1000
tdf#172532 scripting: fix --without-java builds in provider_expandall.py
Change-Id: I81b83e6b5504d452c7ab05754c1296ff90d364e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208991
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
When LibreOffice is built with --without-java, the Java-based
JavaScript provider (ScriptProviderForJavaScript_2) is omitted from
the build and not registered in the service manager. Attempting to
remove it throws a com.sun.star.container.NoSuchElementException.
Additionally, in builds without any active JavaScript provider,
ScriptURIHelper or the master script provider cannot resolve .js files,
causing the test to fail its assertion.
Key changes:
- Catch NoSuchElementException when removing the Java-based JavaScript
provider.
- Safely check if JavaScript script user directories can be retrieved
via ScriptURIHelper.
- Use self.skipTest() if no active JavaScript provider is available to
process script files so the unit test passes cleanly in
--without-java environments.
Change-Id: I69abb006ececb2ca9c285f1de37057a8180d5b8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208924
Tested-by: Jenkins
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Implements XCopyableBrowseNode on the ScriptFile class so that all
script providers based on the single-file provider can support copying.
Change-Id: I14aa057ac432ff80e4a4841fbe5c19be082aa099
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208161
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
The browse node factory had a wrapper using XAggregation that wraps
every XBrowseNode. As far as I can tell this was used to replace the
implementation of getChildNodes with one that checks for exceptions from
the underlying provider and then sorts all of the resulting nodes by
name. The trouble with this is that it prevents the script providers
from detecting when a node is one from the same script provider and thus
makes it difficult to implement the XCopyableBrowseNode interface. The
documentation for XAggregation mentions this problem and also states
that the interface is deprecated.
To avoid this overhead, this patch replaces the aggregation with a
helper function in comphelper that should be used to retrieve children
from a browse node. That takes care of catching exceptions and sorting
the results.
Change-Id: I319888fee1b84ddcef397317d2cf7e72bd2867cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208160
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
The build configuration on the build bots enables both script providers
for JavaScript. One of them will end up being chosen for the
provider_expandall test and that probably depends on non-deterministic
factors such as the order of files on the disk. If the Java-based one is
chosen then the test will fail because it will ignore the temporary
JavaScript macro file created for the test. We do specifically want to
test the QuickJS-based provider in this test case because we want to
make sure the singleprov code is compatible with Python. The Java-based
script provider code will already be tested because of the Beanshell
provider. This patch therefore uses the remove method of the service
manager to just disable the Java-based JavaScript provider.
Change-Id: I265f4cf2191c0c5d08894c700be346ed93d12898
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208226
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
Adds a Python unit test that just tries to retrieve all child nodes from
the master script provider in order to check that they are all
accessible from Python.
Change-Id: I97185b7f21f38a79fdda4078a69d8e88b10cbaed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207349
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Instead of using XInvocation and XPropertySet to expose the optional
edit method, the BASIC script provider now uses the new concrete
interface XEditableBrowseNode.
Change-Id: I7a99a1c335f408da9b0ac26c741577eb449e63c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207348
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
Instead of using XInvocation and XPropertySet to expose the optional
create and edit methods, the script providers based on singleprov now
use the new concrete interfaces XCreatableBrowseNode and
XEditableBrowseNode.
Change-Id: Iae966e554f436b8708699c7d86311f165db2d19f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207347
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Instead of using XInvocation and XPropertySet to expose the optional
create and edit methods, the script providers based on Java now use the
new concrete interfaces XCreatableBrowseNode and XEditableBrowseNode.
Change-Id: Ibc72c434544eb129e30b406d527bef4bb6eea264
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207346
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
Instead of using XInvocation and XPropertySet to expose the optional
create and edit methods, the script provider for Python now uses the new
concrete interfaces XCreatableBrowseNode and XEditableBrowseNode.
Change-Id: Ic5944f2ade291598bac6f39411e86b351ffb0082
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207345
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
The test that checks the editable and creatable properties in nested
directories was always checking them on the provider node instead of the
nested directory node. This was probably due to a cut-and-paste
kerfuffle.
Change-Id: I083c84fff1229553ddaedd99b4f6c11f5127ed70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207342
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
The base script provider in Java for several languages was throwing an
exception when trying to rename an empty library. The browsenodes member
variable was being lazily created when getChildNodes was called but in
the case where there were no children it was being left as null which
was causing a Java runtime exception.
Change-Id: I0d9eac2006bc26d47c22f2e1a7a4424fd67a512f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207152
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses.
By now, weld::Widget and almost all subclasses have
been moved to separate headers, to make it easier
to keep the overview and to avoid having to
recompile ~all UI code when one class changes.
By now, only weld::Button is left in weld.hxx.
Rename the header to Button.hxx.
Drop weld.hxx includes and instead add Button.hxx
includes (or weld::Button forward declarations) where
weld::Button is used.
(Don't simply replace all weld.hxx includes with
Button.hxx ones, since many of them were for the
use of other widgets that have since been moved
to their own headers.)
Add further includes where needed now that the
(direct or transitive) includes of weld.hxx were removed.
Change-Id: I8ea6201446a418d5e38b46337059dcd517ee29d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205937
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Adds a global variable to the QuickJS context called XSCRIPTCONTEXT
which holds an instance of ScriptContext. This makes the scripts more
compatible with scripts written for the Rhino JS implementation and also
more like Python scripts.
Change-Id: I95fd86229786a37c6fff282f45f65555cbde21cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205122
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Adds a generic helper class that implements the XScriptContext
interface. This interface is used in the providers to provide the
XSCRIPTCONTEXT builtin variable. For example for the Python provider it
is implemented in Python code. This C++ implementation can be reused by
any script providers.
Change-Id: I56f23138179555dee84ebf368e8a10cfb2fb4066
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205121
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
Tests that it correctly reads the filesystem to find files, the
Creatable and Editable properties work and that it can execute a script.
Change-Id: I613cf539f256c1ba464fa523f431fcf6e95da5f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204519
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Adds an XBrowseNode implementation for JavaScript scripts using the
QuickJS bindings so that JS files can be found and executed from the
macro organizer. Unlike in Python macros, the entire source file becomes
a single macro instead of trying to find function definitions in the
source.
Change-Id: I73d0c6e6fc6bb7ffd4f6164d1f1887d03bfdfe62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203219
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
This makes the create button enabled for script providers based on
SingleScriptProvider. When the button is pressed the SingleScriptFactory
is queried to get an example script to fill the new macro with and then
the file is created.
This is based on the code for the Python script provider in tdf#56289.
Change-Id: I11a6782e55ba775afed6b62f24ae0d11c347e529
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203283
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
The Editable property is now advertised on script providers based on
SingleScriptProvider. Once invoked, the system default application for
the script will be opened using SystemShellExecute.
On Windows, the default app is queried via AssocQueryStringW and then
passed to the SingleScriptFactory to check if it looks like an
interpreter for the given language. If so, the script is opened in
Notepad instead to avoid just executing the script.
This is based on the code for the Python script provider in tdf#56289.
Change-Id: Ia89ddbdd92b4d76c3a4ce133ffcf9b6d7a9f1e27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203282
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Adds a set of helpers to implement a script provider where the script
files are the entire macro. The provider only needs to make a subclass
of the abstract SingleScriptFactory class to provide the filename
extension, language name and a method to convert the contents of a file
to an XScript. The parts about handling file browsing and reading the
file contents are in the shared helper code.
This is based on the script provider from Luno.
Change-Id: Id39f3a07e887898650b0d77ec493011fb5acc858
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203216
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
There seems to be an idiom used throughout the LibreOffice code where
lastIndexOf is called and then the returned index is checked to see if
it covers the entire end of the string. This should be equivalent to
just calling endsWith but it’s slightly less efficient because
lastIndexOf will pointlessly continue searching other places in the
string if the end doesn’t match.
Change-Id: I4c2c6dd750d41ffabf5d27011c22a4bbb5e32777
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204300
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
Otherwise for example if the filename has spaces in it then these will
appear as “%20” in the macro organiser.
Change-Id: I2da91d5aeb08962c9175219ab75ee7cb9d7277f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203304
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
If a DirBrowseNode points to a file:/// URI then the Creatable property
will now be True. When the Creatable action is invoked it will create a
file with the chosen name and insert an example macro into it.
Change-Id: Ib63da6a2a075ea7c2cf7dcda464b5f61aee53041
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202853
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
This implements the Editable invoke action on ScriptBrowseNode and
FileBrowseNode using a shared mixin class so that when the user selects
a file or a macro in the dialog for organising macros the edit button
will be clickable. When clicked the default app for .py files will be
opened.
On Windows it seems that installing a Python interpreter makes that the
default application for Python files. In order to avoid just running the
script instead of editing it, the code tries to determine what program
is the default by calling AssocQueryString via ctypes. If it looks like
a Python interpreter the python file will be opened with notepad
instead. Otherwise the document is opened with the “open” verb via
os.startfile.
On all other platforms the file is opened with SystemShellExecute. On my
Mac this ends up opening it in XCode. On my default Fedora install this
ends up opening the script in gedit which is probably quite a good
default. Hopefully there are no distros that default to executing Python
scripts when passed to xdg-open.
For some reason SystemShellExecute doesn’t seem to do anything on
Windows which is why os.startfile is used instead.
Change-Id: If37ee13aea0200cd6b20230bd92a77aa6a0d3273
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202852
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Adds an implementation of XInvocation and XPropertySet to
PythonScriptProvider that just passes on all the methods to the wrapped
dirBrowseNode. If we don’t do this then the root browser nodes can’t
report that they are Editable or Creatable.
Change-Id: I2ddab92910ab0cb34866246844669c63b2f66671
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202851
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
The ensureSourceState function assumes the source code is a bytes object
but the editor was passing it the result of calling getText on the
editor control directly, which is a str object. This was making it throw
an exception.
Change-Id: Id96b22c2b43667cd4b4b245cfeff5a6d2cca6fc5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202744
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
pythonscript.py has code to use a simple editor dialog. It is disabled
by default but it can be enabled by setting ENABLE_EDIT_DIALOG to True
in the source code. It wasn’t working however because the file for the
dialog had been removed in the following commit:
commit a1552a0ec3
Author: David Ostrovsky <david@ostrovsky.org>
Date: Thu Oct 9 10:47:42 2014 +0200
Scripting: Remove org package
The file was still declared in dialog.xlb so I wonder if the removal was
a mistake.
Change-Id: I7e4bca02bb5a5a92986336f6916505bf572b0ecd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202743
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
SystemEnvData holds data specific to a single
frame/object, but the toolkit used is specific
to the SalInstance/vcl plugin.
Instead of having a SystemEnvData::toolkit member
that needs to be set for each object, introduce
a SalInstance::GetToolkit getter and a corresponding
Application::GetToolkit that calls it.
Change-Id: I052f122e991bec745af88d3f43847e4d77fb4ba4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201536
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Since some code needs flexibility in error handling, where hardcoded
error value of -1 wasn't handy, o3tl::convertToHex was changed to
accept the error value as its template parameter.
Change-Id: Ifc771cc8fa29a801d4556dea969fc3ea7e620df5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199367
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I5b23b02151c75bb49831a2bbf8d515eb0b54415e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199068
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This is in preparation of moving code out of weld.hxx
to separate headers/source files, in order to make it
easier to keep an overview and to avoid having to
recompile ~all UI code when anything changes.
Also move weldutils.cxx to a new vcl/source/weld
directory.
Change-Id: Ia75b42f21e560dd248307282a522f186a64cd742
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195777
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
utl::MediaDescriptor was just a SequenceAsHashMap with a few added
methods. It made it more difficult to assign a SequenceAsHashMap to
MediaDescriptor, without real upsides. In many places, the class was
used not as media descriptor, but just as helper to create sequences.
This change puts the string constants and the former methods into a
namespace utl::MediaDescriptor.
It would be also good to drop comphelper::NamedValueCollection, which
is basically a twin of comphelper::SequenceAsHashMap (TODO).
Change-Id: Ia9b69c5a2ad153ecc654944c419c1880252ed86e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195163
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>