summaryrefslogtreecommitdiff
path: root/static
AgeCommit message (Collapse)Author
2024-09-02Explicitly .delete() one more interface object in uno.jsStephan Bergmann
...accidentally left over from 91842724235bca73690d67d8084ec7581512d791 "Explicitly .delete() type and interface objects in uno.js" Change-Id: I84b1b7b5ee283a1a87f5d3aa894776b1bf23c607 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172731 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-08-31Explicitly .delete() type and interface objects in uno.jsStephan Bergmann
These objects use smart proxies, so Embind adds them to a JS finalizer (in JS runtimes where FinalizationRegistry is available), so it shouldn't be necessary to manually .delete() them, but Embind then emits "Embind found a leaked C++ instance..." warnings about them, which clutter the JS console. While it is probably impractical for client code to manually .delete() all such instances, we can at least explicitly .delete() those that occur in uno.js itself. Change-Id: Ia21ca5f0bdb246cc5ea272599befd9a16bc970a8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172661 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-08-30Consistenly terminate statements with semicolons in JS codeStephan Bergmann
Change-Id: Ie52917f6f487f5de2d67179f67f2935a1f6c838a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-08-29tdf#161826 - Add uniform Glow effect for texts in shapesBalazs Varga
- Add new text Glow effect properties for shapes - Using TextGlowPrimitive for rendering uniform text glow in shapes - Add/allow new UI Glow Effect for texts in shapes on sidebar (Only for Impress/Draw and Calc) - Import/Export ooxml files with Glow effect on texts in shapes (Only PPTX/XLSX) - Import/Export odf files with Glow effect on texts in shapes - Add unit test for glow text attributes in ODF - Add uni tests for OOXML import/export Note: Also this patch effects on tdf#144061 - Effects: Allow GLOW to apply to Text (as we have for shapes) Change-Id: I16586c01654f197f532129e4e06aa2ef9f214395 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172216 Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de> Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-08-29use emrun with explicit "--hostname 127.0.0.1" for testingMoritz Duge
Minor security improvement. See https://github.com/emscripten-core/emscripten/issues/22077 Change-Id: I05d632f6023883672d0e1b2586f53df87dd7d874 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172540 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Reviewed-by: Moritz Duge <moritz.duge@allotropia.de>
2024-08-26+WARN is the default with an unset SAL_LOG env var, anywayStephan Bergmann
Change-Id: Ia8bbc1bdc09705f1ecab783d0d73a417f0ef84e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172378 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-08-26'use strict' is of no use here...Stephan Bergmann
...in snippets that are included with --pre-js/--post-js Change-Id: I928aa16b78284314796a0645479dce0dfc7b42cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172383 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-08-20More useful to have an EMSCRIPTEN_EXTRA_SOFFICE_PRE_JSStephan Bergmann
...than an EMSCRIPTEN_EXTRA_SOFFICE_POST_JS. That way, we can e.g. set up Module.arguments there. Change-Id: I4990ab6daac2f74326ab2ee9508828f1b79bceb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172154 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-08-20Remove wasm-qt-mandelbrot demoStephan Bergmann
...that had been added with f90c68316c622971706568303a025bbc58351df3 "WASM: add Emscripten demo application". Whatever the original intention, it has probably served its purpose by now---and now only negatively impacts (re-)build times. Change-Id: I2bda8d12b91e741c4d0f7d3f02597e0e9505a73a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172087 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-08-19Fix typoAndrea Gelmini
Change-Id: I3277386244f3a00c2756525829924870e3a3d2bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172030 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-08-19Fix typoAndrea Gelmini
Change-Id: I3fac3dcde5aad559dcbc4c64aeedfd0f6fc1cd6c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172029 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-08-18Emscripten: Document how Qt builds its own freetype, but we link against LO'sStephan Bergmann
Change-Id: I6413c64db3d50f163ee9cc4feda395a54aab3cf2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172012 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-08-15Emscripten: Establish a channel between browser and LO main threadsStephan Bergmann
...to be used by external code, to mitigate the issue mentioned in the commit message of cccc983eb3f0532dbf7e3edf4477ce63ec3d2795 "Emscripten: Run external code on LO's main thread": "Alternatively, running external code on the browser's main thread rather than on LO's main thread could be more ideal in the sense that the external code would then have access to the browser's document object." On the browser main thread, external JS code can now await a Module.uno_main Promise that provides one port of a MessageChannel. And on the LO main thread, external JS code has access to the other port of that MessageChannel as Module.uno_mainPort. (And the external code is completely free in what onmessage handlers to set up and what form of postMessage calls to use on those two MessagePorts.) Change-Id: Iab6bc7676c744eacb70ddd9f3f80f64e9efd1cf1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171907 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-08-14Emscripten: Run external code on LO's main threadStephan Bergmann
...and not the browser's main thread. Those are different threads now since 6e6451ce96f47e0ef5e8ecf1750f394ff3fb48e4 "Emscripten: Move the Qt event loop off the JS main thread". Running `Module.uno_init.then` on the browser's main thread would never trigger, as that promise is only resolved on LO's main thread. When external code was included in soffice.js via EMSCRIPTEN_EXTRA_SOFFICE_POST_JS, that didn't make a difference: Emscripten effectively replicates that code to all the worker threads, so whatever worker thread resolved the Module.uno_init promise (i.e., the LO main thread) had the external code available and ran it. But when external code was included directly in some HTML file (which "manually" provides a canvas and loads soffice.js, not relying on the qt_soffice.html convenience functionality), it was available in the browser's main thread but not in LO's main thread. For that use case, introduce a new Module.uno_scripts array that can be set up in the HTML file to contain an array of URLs (represented as strings) of scripts to load into LO's main thread. (Alternatively, running external code on the browser's main thread rather than on LO's main thread could be more ideal in the sense that the external code would then have access to the browser's document object. But, for one, it would be less ideal in the sense that we would then potentially again execute LO code (which we call into from the external code via UNO) on the browser's main thread, which would bring back the issues that 6e6451ce96f47e0ef5e8ecf1750f394ff3fb48e4 "Emscripten: Move the Qt event loop off the JS main thread" solved. And, for another, when I experimentally tried it out, it caused massive Qt threading issues, so I quickly gave up again.) Change-Id: If01a7859751706f168e93ccac75758ae5ce17cd2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171870 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-08-12Emscripten: Move the Qt event loop off the JS main threadStephan Bergmann
...so that spawning and joining new threads works now and we no longer need a hardcoded -sPTHREAD_POOL_SIZE of pre-spawned threads (see b84ef4d67eaf9f9fd7fd700ca05339cb0cdff742 "Adapt comphelper::ThreadPool to Emscripten's threading needs"; lets keep MAX_CONCURRENCY capped at 4, at least for now, though). This requires <https://github.com/allotropia/qtbase/commit/167b08844df06e3cea85c98161b26e97442ab242> "Minimal support for Emscripten -sPROXY_TO_PTHREAD=1" and <https://github.com/allotropia/qtbase/commit/c722a25630a5390f18a4d974aa942f6376fcb8e1> "Implement QWasmCursor::changeCursor for Emscripten PROXY_TO_PTHREAD case" (see TODOs there). Change-Id: I8cea827bd7786e3c9fd9401b4b2bef9d3ec00d5a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171758 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-08-07I finally understand why we need that hackStephan Bergmann
...that 77129fbb74bcefde4551d494f029169e7c6026e3 "Emscripten: Add hack to prepare for --enable-wasm-exceptions" was puzzled about Change-Id: Iba54a77e3c2a71fe45b97795ca2da0606c3adf41 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171594 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-07-30Embind: Missing support for UNO polymorphic struct typesStephan Bergmann
Change-Id: I6bb29a951e6e5a3ed7d825172ba7b92ef95a5619 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171228 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-07-26Add --with-package-format=emscriptenStephan Bergmann
...to have $(WORKDIR)/installation/LibreOffice/emscripten populated with just the relevant files from $(INSTDIR). (This doesn't reuse the complicated CustomTarget_instsetoo_native/install used for other PKGFORMATs; as a special case, it uses a much simpler CustomTarget_instsetoo_native/emscripten-install.) Change-Id: I9c7509aadbc0e6e49ec95bf51c748c2ff9f778b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171066 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-07-26Looks like Emscripten LO doesn't need explicit --norestore --nologoStephan Bergmann
...mostly because the relevant parts of the code are hard-disabled (even if you would --disable-wasm-strip) with ENABLE_WASM_STRIP_RECOVERYUI=TRUE and ENABLE_WASM_STRIP_SPLASH=TRUE. (And if there are places in the code that would need the equivalent of either --norestore or --nologo after all, we could probably better add explicit #if EMSCRIPTEN there instead.) This allows to get rid of hard-coding the Qt Emscripten LO command line arguments, which means that e.g. web applications embedding LO would now be able to specify them themselves. Change-Id: I8e2dcfd170cc32276bfb9007f098f6ae6a7f9ec1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171063 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-07-25Add a toDelete parameter to Module.throwUnoExceptionStephan Bergmann
...as there can be situations (cf. the newly added test code in embindtest.js) where objects that need to be deleted are passed as payload of the exception value to be thrown. So there now is a (mandatory, as Embind doesn't allow to implicitly pass undefined) third parameter now that must be an array of objects on which to call .delete(). (75fe059974dcb80c3f78110c73ab799afc6f4ca3 "Embind: throwUnoException from JS" had deliberately made throwUnoException take two arguments, because if it "directly took a css::uno::Any argument, JS client code would need to create one with `new Module.uno_Any(...)` and call .delete() on it, but there is no place where it could call .delete()". There now would be such a place, but it would probably still be tedious most of the time to explicitly construct a new uno_Any to pass into throwUnoException both as the exception and in the toDelete array. So keep that design decision to have throwUnoException take individual type and value arguments.) Change-Id: Idec029d9e500457b02d20d899b9a2328cd7a5d7e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171024 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-07-25Enable start center in Emscripten buildStephan Bergmann
...and let it open with that instead of with a hard-coded example.odt. (But keep that example.odt in CustomTarget,static_emscripten_fs_image and adapt the example code in static/README.wasm.md to explicitly load it now.) Change-Id: Ie43e3795e44542acba5a8e755f65acc56fa753f8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171019 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-07-25Adapt comphelper::ThreadPool to Emscripten's threading needsStephan Bergmann
...by keeping the worker threads around by default instead of joining and later re-spawning them; see 5b1df7709d75c6dd993da5a272e7e37e55a70174 "Document the Emscripten threads issue". But lets be cautious and change the bJoin default only for Emscripten. Also, cap the thread pool size to MAX_CONCURRENCY=4 and increase to -sPTHREAD_POOL_SIZE=6. In an experimental setup where the Emscripten build starts up with the start center rather than a Writer document, that is just enough to cover the thread-spawning needs when executing the start center window's paint task: Four threads for the comphelper::ThreadPool (used from within drawinglayer::convertToBitmapEx -> ... -> BitmapBasicMorphologyFilter::filter), and one each for configmgr::Components::WriteThread (see e8358d0a0f7c2c4b1ccf800fe9ec8a7f2bf7066a "Keep around a single configmgr::Components::WriteThread instance") and salhelper::TimerManager. Change-Id: I5b1d0e9dc09f05fb3b679c8dc1c38ee45c61c0f8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171004 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-07-25Fix typoAndrea Gelmini
Change-Id: I465502f90e0ce458f6746efa6e558896f6bea5ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170999 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2024-07-24Document the Emscripten threads issueStephan Bergmann
Change-Id: Ia26b48d46283a9528a665eb5028bd5b9bd0dd953 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170972 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-07-19Drop obsolete "Ideas for an UNO bridge implementation"Stephan Bergmann
Change-Id: Ibf1de9cf8dc18e62b5ee67b31a8e3f3748c3941b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170769 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-07-18Change from Module.intiUno() to Module.uno_init promiseStephan Bergmann
...that is resolved from within C++ Desktop::InitApplicationServiceManager once UNO is fully initialized, so client code can trigger on Module.uno_init.then(...) Change-Id: I2d4c542d9729d09f434502e3f966e9ee474e926c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170683 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-07-16Embind: Implement UNO interface attributes as JS accessor propertiesStephan Bergmann
Change-Id: I39b1f5676b2e5ba6071b39bf031c10d9c85f1ad1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170566 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-07-12A mechanism for annotating the embindmaker-generated JS UNOIDL dataStephan Bergmann
As we need to generate data upfront for all the UNOIDL entities anyway, we might just as well extend that with annotations (keyed to some new Module.unoTagSymbol) that are useful at runtime. The general idea is to let such annotations be objects with certain well-known keys, the main one being a string-valued `kind` representing the UNOIDL kind of the annotated data. As a first thing, individual UNOIDL enum type enumerators are annotated with a `type` representing the UNOIDL enum type they belong to. That turns out to be useful for some experimental approach of mine where I wrap the Embind-based JS binding in something that makes the result more idiomatic JS. Change-Id: Iec466bab05ba3d1b56b2398e5c361465af49dc13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170398 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-07-11Rename wasmcallgen -> wasmbridgegenStephan Bergmann
...to acknowledge the tools' more general role since 74829f2a64b6989ddf1d126a6fd2f2d2e9000d3b "Fully implement the Wasm UNO bridge cpp2uno direction" Change-Id: Ie89255579774035f7b726d1d4b029dc536893ca0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170382 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-07-11Fully implement the Wasm UNO bridge cpp2uno directionStephan Bergmann
...after 875997c8962da7f6b72950b201186a19b3c20d3a "Properly implement cppu::throwException for Emscripten" had implemented only those parts that were absolutely necessary for that exception throwing. As detailed in the commit message there, wasmcallgen has been extended to additionally generate all the required vtable slot call trampoline code (which cannot be generated on the fly for Wasm, as would be done for other platforms). Consequently, some of the "callvirtualfunction"-centric file names have been changed to "generated" as the output of wasmcallgen is now more general. (And wasmcallgen itself should also be renamed, in a follow-up commit. And when adding to the wasmcallgen code here, some existing parts of its implementation have been cleaned up, too.) There is no direct way to test this half of the Wasm UNO bridge directly from unotest/source/embindtest/embindtest.js, so a new org.libreoffice.embindtest.BridgeTest singleton has been added, which triggers new test code in unotest/source/embindtest/embindtest.cxx that tests the bridge in a way similar to testtools' bridgetest machinery. Change-Id: I521a1d6c2160aedc814f7603b0b99861e5fbd1eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170374 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-07-10Properly implement cppu::throwException for EmscriptenStephan Bergmann
...by implementing (for now) just enough of the cpp2uno half of the Wasm UNO bridge to make it work. In general, that half suffers from the same issue as the already-implemented uno2cpp half, namely that Wasm doesn't allow to generate code on the fly (which, in this case, would be needed to implement the vtable slot trampoline functions). So, for now just hard-code the few vtableSlotFunction_* that are needed by the UNO interfaces for cppuhelper/source/exc_thrower.cxx. (A proper fix would probably use the same approach as for the uno2cpp half, and use something like wasmcallgen to generate at least all the vtableSlotFunction_* needed for udkapi/offapi upfront.) The RTTI for the exceptions needs to be unique across the executable for exception catching to actually work (as it compares exception types by RTTI address rather than by name). We thus need to export all the relevant RTTI symbols (which I hacked into the existing wasmcallgen for now, even if that makes that executable's name a slight misnomer now), and access them with a new jsGetExportedSymbol. (This exporting would also be needed by the "classical" approach of using dlsym on the main module, cf. <https://gerrit.libreoffice.org/c/core/+/167187> "WIP: Emscripten: Set up support for dlsym from main module". And while that dlsym approach would work, it is much simpler to just use that jsGetExportedSymbol than to use a dlsym detour, and thereby avoid all the hassle of -sMAIN_MODULE detailed in the commit message of that Gerrit change.) It also turned out that including Emscripten's <cxxabi.h> needs __USING_WASM_EXCEPTIONS__ to be defined, because it uses that in its declaration of __cxa_throw. (The source for setting that define internally in Emscripten is get_cflags in the emsdk's upstream/emscripten/tools/system_libs.py, which defines __USING_EMSCRIPTEN_EXCEPTIONS__ for the non-Wasm, Emscripten JS exception mode, and defines __USING_WASM_EXCEPTIONS__ for --enable-wasm-exceptions, which we use. The commit message of f4ec967599f5dafa1ce477631d7c2e8de005e28f "Fix redefinion of Emscripten __cxxabiv1::__cxa_exception" documents my prior confusion of when one or the other would be defined.) Change-Id: Id08765ab5b4ce1553dc3a61648324526185cb64c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170246 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-06-21Embind: Fix C++ UNO exception catchingStephan Bergmann
...with a new Module.catchUnoException JS function that can be used in a JS catch block to provide the thrown UNO exception as an Any. (For a non-C++ exception, it rethrows the exception, and for a non-UNO C++ exception it maps it to css.uno.RuntimeException.) The implementation reuses parts of bridges/source/cpp_uno/gcc3_wasm/, which have been moved to a new StaticLibrary_emscriptencxxabi. Change-Id: I708fe6121c43a1b9736de5dff449f6c4f32a45f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169325 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-06-19makefile simplification: replace $(call gb_AutoInstall_get_target,foo)Christian Lohmaier
by a simple/static $(gb_AutoInstall_targetdir)/foo and also drop the custom .dir target Change-Id: I4893c2675cb076cb8a0b61c0c207a223658b43d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168709 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-06-19Consistently 'use strict' for JS codeStephan Bergmann
Change-Id: I6f6e06ad32ffa87242f5a0f41c176149b754e2ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169187 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-06-18Embind: Add the lifecylce fix also for attribute getter return valuesStephan Bergmann
...which had accidentally been left out at 04658a706757dabbedfd87717e6f1f354b4c8961 "Embind: Fix lifecycle of UNO any and sequence values returned from JS to C++" Change-Id: I7ec1766850049cb5032020b65ccc171027f739b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169113 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-06-17Embind: Fix lifecycle of UNO any and sequence values returned from JS to C++Stephan Bergmann
When a JS function implementing a UNO interface method returns any or a sequence type (like queryInterface, getType, and getImplementationId in uno.js), it could not create a new instance of that type and return it, as it would have needed to call .delete() on that instance, but couldn't. In uno.js, getType and getImplementationId solved that by returning pre-instantiated instances that were deleted in the final release call. But that did not work for queryInterface, as pre-instantiating the relevant any instances would have caused cyclic references that would have caused the final release call never to occur. So redesign the C++ the_wrapper classes (used by the Embind allow_subclass machinery): If a UNO interface method returns any or a sequence type (i.e., a type on which .delete() must be called), change the JS implemenation's return type from by-value (which meant that the C++ code received a copy) to by-reference---which means that now the C++ code can access the original instance and delete it. But which also means that the JS code must always return a fresh instance now! (Ideally, the embindmaker-generated code would use by-pointer rather than by-reference for that return type, but that caused > emsdk/upstream/emscripten/cache/sysroot/include/emscripten/wire.h:116:19: error: static assertion failed due to requirement '!std::is_pointer<com::sun::star::uno::Any *>::value': Implicitly binding raw pointers is illegal. Specify allow_raw_pointer<arg<?>> > 116 | static_assert(!std::is_pointer<T*>::value, "Implicitly binding raw pointers is illegal. Specify allow_raw_pointer<arg<?>>"); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ errors with no obvious place where to put such allow_raw_pointer markers, so lets go with this little hack at least for now.) Change-Id: I3c37b79b8fbf09c19782c6532bc95d4d63505c63 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169008 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-06-17Fix thinko re JS for...in loopStephan Bergmann
Change-Id: I31647952090224e3195afc636613d1ae56ecb10e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168995 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-06-12Embind: Let unoObject return a css.uno.XInterface referenceStephan Bergmann
...and confine the _impl map to an internal detail. Client code should have no need to access that _impl map (renamed here to impl_interfaces), nor the Module.uno_Type_*.reference functions (nor the Module.uno_Type_*.implement functions). Change-Id: Ic9c74f22cedb9b5eeecb42d7c13ee0555e92690d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168732 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-06-12Remove leftover work-in-progress lineStephan Bergmann
Change-Id: I0faf224ea51df733cba2edc5e52b1a71c0e96140 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168731 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-06-12Embind: Centrally initialize via Module.initUno() in a new uno.jsStephan Bergmann
...so that the unoObject function can be moved there too (so that other code outside embindtest.js can reuse it) Change-Id: Id3edb7cede56321db29ba435f221cb7702a3513c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168700 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-06-07Embind: Add some type-inquiry functions to uno_Type and uno_AnyStephan Bergmann
...that proved useful in experiments wrapping a JS Proxy around the Embind representation of C++ UNO objects. Change-Id: Ia4018ec8dee2c222fb76ba8e2f529f4845f0134c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168518 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-06-05embindmaker: Fix names for "uno_Sequence_unsigned hyper" etc.Stephan Bergmann
...to rather be "uno_Sequence_unsigned_hyper" etc. (without an embedded space) Change-Id: I1a02a12077a1e0a5468dc3c0d04f86bb0e951670 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168478 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-06-05Clean up example codeStephan Bergmann
* Consistently use `const` to introduce variable bindings. * Don't rely on `xText` from the first example in the second one. * No (more) need to query for base interfaces. * No (more) need to delete interface references. * Add a missing delete of Any `next`. * Remove a redundant empty line. * Adapt to our 100 character line width. Change-Id: Ie116021a4b0cc6d88c6204e7ea5147a837c251f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168405 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-05-29Emscripten: Unconditional --enable-wasm-exceptionsStephan Bergmann
(...which will be beneficial, in turn, to implement exception handling in the work-in-progress bridges/source/cpp_uno/gcc3_wasm UNO bridge). As per <https://developer.mozilla.org/en-US/docs/WebAssembly#browser_compatibility>, Wasm exceptions appear to be supported by most if not all relevant engines by now. * Lets see whether the "Note that to really use WASM exceptions everywhere" for external libraries in solenv/gbuild/platform/EMSCRIPTEN_INTEL_GCC.mk does have any practical consequences (but ignoring it for now). * This change depends on the preceding 77129fbb74bcefde4551d494f029169e7c6026e3 "Emscripten: Add hack to prepare for --enable-wasm-exceptions" to work around the issue that was mentioned in static/README.wasm.md. * In unotest/source/embindtest/embindtest.js, getExceptionMessage started to work now, no longer exhibiting the RuntimeError that had been documented there for non-Wasm-based exceptions. Change-Id: Ifa2165b62208cc927844684911ddf21a4a2b624f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168169 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-05-28Emscripten: Add hack to prepare for --enable-wasm-exceptionsStephan Bergmann
(...which will be beneficial, in turn, to implement exception handling in the work-in-progress bridges/source/cpp_uno/gcc3_wasm UNO bridge). Once setting --enable-wasm-exceptions, plus the corresponding -sSUPPORT_LONGJMP=wasm in qt5, I indeed started to see the "RuntimeError: null function or function signature mismatch" that was already mentioned in static/README.wasm.md. I could track it down to the early destruction of the aDesktop local variable in soffice_main, as I now explain there. However, it beats me why that variable gets destroyed early. The desktop::Desktop::~Desktop dtor claims to be called from within main -> soffice_main -> desktop::Desktop::~Desktop, but at a time when the call to main -> soffice_main -> SVMain has not yet returned. There also does not appear to be any C++ exception handling stack unwinding going on. (It could be related somehow to -sSUPPORT_LONGJMP=wasm, I don't know.) And everything appears to just work fine after turning that aDesktop local variable into a (leaked) heap instance instead, so go with that hack for now... Change-Id: I8e00c988ee9a44fd3befbe41c844eec050f0e509 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167694 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-05-09Embind: Fix uno_Any.get for null interface valuesStephan Bergmann
...which had caused an additional getNull/isNull check for a469aea9c0b532d928cd41e389c9c51de1af06f0 "Emscripten: Towards a working C++ UNO bridge" to fail Change-Id: Ibe87ca05f795253c9ede8cab6f96da8fe4496f87 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167344 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-05-08Emscripten: Towards a working C++ UNO bridgeStephan Bergmann
...by making the general UNO -> C++ function call case work (modulo handling exceptions, which I'll look into later). Wasm call_indirect unfortunately needs to statically know the call target's signature, so we statically need to know all possible signatures. So introduce wasmcallgen helper to scan the existing UNOIDL API upfront and generate the relevant callvirtualfunction-wrapper.cxx and callvirtualfunction-inst.s code. (The good thing is that the number of different signatures is somewhat limited, each parameter can only be one of i32, i64, f32, or f64. So even if 3rd-party extensions bring along new UNOIDL interface methods, chances are relatively high that the signatures needed for them would already be covered by the existing ones.) Testing this can nicely be done in unotest/source/embindtest/embindtest.js via css.script.Invocation (which internally exercises the relevant code). (Instead of adding individual org.libreoffice.embindtest.StructLong/String etc., it would be nicer to introduce some polymorphic StructOne<T>, but the Emind UNO binding does not support polymorphic structs, so the embindtest.js code would not work.) Change-Id: If829c9e3772bfd27561f3ad743d38a71d11545b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167308 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-05-03makefile simplification: replace $(call gb_CustomTarget_get_workdir,foo)Christian Lohmaier
…by a simple/static $(gb_CustomTarget_workdir)/foo The build system has a lot of overly complicated leftovers from when it was introduced and had not only deal with split repositories but also had to coexist with another buildsystem. Along with lots of copy'n'paste along the years the makefiles became hard to grasp for newcomers with all our calls and evals. As a first step to streamline that, the macros from TargetLocations that simply prefix a static path to the argument (and similar of the same kind) are a natural pick before simplifying the rules themselves/getting rid of a bunch of eval statements. Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-05-02use [[noreturn]] instead of asserts that badUsage exitsCaolán McNamara
Change-Id: I927434290b02b6cc0386b1e0038cd8385a762249 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166996 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins
2024-04-30Embind: Fix out-param handlingStephan Bergmann
...by using UnoInOutParam in all cases. Some types whose Embind mappings don't employ any smart pointers (like any and sequence) would have worked directly with pointers, but others (like string and type) would have caused Embind errors at runtime. So consistently use UnoInOutParam in all cases (and generate bindings for all the used cases in embindmaker). Change-Id: If26551bf4e99d10748aec1597d6e99f994dfd86e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166854 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
generated by cgit (git 2.34.1) at 2024-12-24 19:55:56 +0000