https://bz.apache.org/ooo/show_bug.cgi?id=60849
--- Comment #4 from [email protected] --- Confirming, still can't edit Python macros or embed them in documents through the UI. As I began discussing on bug 75132, in main/scripting, we have a full-featured Java-based ScriptProvider in subdirectory java/com for Java, BeanShell and Javascript (Rhino), and then we have a small partially working ScriptProvider for Python in subdirectory source/pyprov. It is this Python ScriptProvider that holds us back in terms of Python editing and embedding, and either it has to be (A) extended to support all the necessary operations, or (B) replaced by another ScriptProvider that does. In terms of the Java-based ScriptProvider, it has a total of 43 files and 9653 lines of code, deals with embedding macros in documents, and even has user interaction such as showing dialogs to allow users to enter names of libraries and macros when creating / renaming them, or confirm deletion... That, plus the fact that BeanShell, Javascript and Java require as little as 1-2 custom classes (see main/scripting/java/com/sun/star/script/framework/javascript/ScriptProviderForJavaScript.java), and most of the code is reused between them, led me to try option B in the previous paragraph, that is, adding a ScriptProviderForPython.java that replaces source/pyprov's Python-based provider. And how did that go? Well, it kind of works, a "Python" macro type is shown in the UI, you can create and embed Python libraries in documents which is a huge improvement, but arguably the most important part - actually running Python macros - would require Java to run Python code: ---snip--- public Object invoke( /*IN*/Object[] params, /*OUT*/short[][] aOutParamIndex, /*OUT*/Object[][] aOutParam ) throws ScriptFrameworkErrorException, InvocationTargetException { // Now you see the problem... we have the parameters in Java, // but we need them in Python! } ---snip--- So we would require double marshaling in UNO: from C++ -> Java, then again Java -> Python, for each macro call, which would be terrible for performance. This probably explains why a separate ScriptProvider was developed just for Python. Are we forced to take option A (extend the Python ScriptProvider), porting nearly 10000 lines of code from Java to Python? -- You are receiving this mail because: You are the assignee for the issue. You are on the CC list for the issue.
