[dev] Re: Farewell
Dear Niklas, it is sad to learn that you will not be able to keep up your great and constructive help! Whatever you are up to: all the best and good luck! However: should you have some spare time, then please keep up your great help, even it is only possible once a month! :) All the best, ---rony On 04.09.2011 18:56, Niklas Nebel wrote: In case anyone is still reading these lists: I have left Oracle and started a new job, not related to OpenOffice.org. Because of this, I won't have enough time for any meaningful participation in the new OpenOffice.org at Apache. So it's time for me to say goodbye. OpenOffice.org has always been great fun for me, so I'm happy to see some familiar names in the Apache project, which makes me confident they will be able to continue the success of OpenOffice.org. Thanks everybody for a great time! Niklas -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Announcing the new release of BSF4ooRexx, 2011-08-22
Hi there, the following announcement points at a nice tool that allows one to research and document the UNO definitions via reflection. In addition, it allows any programmer from any programming language to use that particular functionality via the UNO dispatch interface. The input is either via a GUI, supplying the /fully qualified name of an UNO class, UNO enumeration/ etc., *or */dynamically by an UNO dispatch supplying a runtime object being of any UNO object type/. After installing the BSF4ooRexx package (which needs ooRexx 4.1 installed from http://www.oorexx.org/download.html) go to the BSF4ooRexx-menu and pick Utilitiites which opens a directory. Change into the OOo subdirectory, then UNO_API_info subdirectory. * There you will find a html-file documenting and explaining the utility and also gives examples in *OOo BASIC*, *Java*, *JavaScript*, *ooRexx *and *Python *that demonstrate how to take advantage of that functionality from running programs. (This e.g. allows one to pass on any UNO object, that as a result will get documented with its interfaces and hyperlinked to the official OOo documentation pages.) * To run the GUI just double-click on frontend_UNO_API_info.rxo. Some more information * usually OOo is installed in 32-bit; if so, then install the 32-bit ooRexx interpreter for your system, followed by the matching BSF4ooRexx installation (the bitness of ooRexx, OOo/LO, BSF4ooRexx and Java must match), * BSF4ooRexx is a language binding, that bridges ooRexx and Java; as a matter of fact, Java will get masked as a dynamically typed, caseless language; this allows one to use all of Java, without being a Java programmer! o BSF4ooRexx has special built-in support for OOo which uses the OOo-Java binding. o There is more information about the OOo/LO support, if you go to the BSF4ooRexx download page and scroll down to the very end: https://sourceforge.net/projects/bsf4oorexx/files/BSF4ooRexx-406.20110822-GA/. Attention Mac users: the current implementation of OOo on Mac has problems with regards to dispatching Rexx scripts as macros from within a running OOo document. This can only be fixed by a new version of OOo. (It is still possible to use the OOo support on Mac running the standalone Rexx scripts via the command line, including the GUI UNO_API_info tool.) If you have any questions, please do not hesitate to ask them. ---rony --- cut here Announcing the new release of BSF4ooRexx, 2011-08-22 After an extensive test period the development team of BSF4ooRexx is proud to announce the general availability (GA) of BSF4ooRexx, version 4.06, 20110822! BSF4ooRexx is a language binding for the easy to learn and powerful scripting language ooRexx (http://www.ooRexx.org), which allows ooRexx programmers to directly use the Java Runtime Environment (JRE) installed on practically every computer. The language binding camouflages Java as a dynamically typed, caseless language, making it extremely easy to exploit Java by non-Java programmers. BSF4ooRexx comes with a built-in support for programming OpenOffice.org/LibreOffice.org and allows ooRexx to be used as a macro language. Some notable features of this version of BSF4ooRexx: - for the first time GUI-based installers for Linux, MacOSX and Windows, - camouflages the strictly typed and case-dependent Java language as an easy to use, dynamically typed, caseless language, - makes it easy for ooRexx programmers to exploit all functionality Java offers in a platform independent manner (ooRexx scripts using BSF4ooRexx can run unchanged on Linux, MacOSX and Windows!), - allows to implement Java methods in ooRexx (interface and abstract Java methods), - allows Java/NetRexx programmers to directly interact with ooRexx objects (sending ooRexx messages, supplying arguments, fetching return values, catching ooRexx conditions), - for the first time a new, platform independent GUI-based editor for testing ooRexx code interactively, - new support for MacoSX, the MacOSX version of BSF4ooRexx includes a version of ooRexx built from the ooRexx 4.1.1 branch, - integration of Java awt/swing into the MacOSX user interface (Apple menu, etc.), - a GUI-based on-the-fly documentation tool for OpenOffice.org/LibreOffice.org classes, - and much, much more ... The BSF4ooRexx project now resides at sourceforge and has become an official project of the non-profit special interest group Rexx Language Association (RexxLA). RexxLA is also the owner of the easy to learn, yet powerful scripting language ooRexx and of NetRexx, the first Java language with a Rexx syntax. Home:http://sourceforge.net/projects/bsf4oorexx (new!) RexxLA: http://www.RexxLA.org ooRexx: http://www.ooRexx.org NetRexx
[dev] Re: Replacing LGPL libraries: Use of lp_solve for Calc's linear solver
On 11.06.2011 17:55, Niklas Nebel wrote: On 11.06.2011 17:43, rony wrote: On 11.06.2011 17:36, Niklas Nebel wrote: Dependencies on LGPL libraries may soon become a problem. What would be the problem here? [Just curious why it was o.k. in the past, but may be a problem soon ?] http://www.apache.org/legal/3party.html Ah, I see! Thanks. ---rony -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Replacing LGPL libraries: Use of lp_solve for Calc's linear solver
Hi Ariel, On 11.06.2011 20:26, Ariel Constenla-Haile wrote: Hello rony, On Saturday 11 June 2011, 12:43, rony wrote: Hi Niklas, On 11.06.2011 17:36, Niklas Nebel wrote: Dependencies on LGPL libraries may soon become a problem. What would be the problem here? Oh, haven't you been following the OOo Apache Incubator Proposal? http://wiki.apache.org/incubator/OpenOfficeProposal http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/thread (almost 1000 mails) The thing is that Apache only releases code under the AL. thank you very much, especially for the links ! [Just curious why it was o.k. in the past, but may be a problem soon ?] One such library is lp_solve, which is the basis of the OpenOffice.org Linear Solver in Calc. It would certainly be a nice twist of irony if the evil-grasping-Sun-solver Again, not sure what you mean with evil-grasping here? http://osdir.com/ml/gnome.ximian.openoffice/2008-04/msg00073.html Ah, I see! :) Again, thank you *very* much for the link! ---rony -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Replacing LGPL libraries: Use of lp_solve for Calc's linear solver
Hi Niklas, On 11.06.2011 17:36, Niklas Nebel wrote: Dependencies on LGPL libraries may soon become a problem. What would be the problem here? [Just curious why it was o.k. in the past, but may be a problem soon ?] One such library is lp_solve, which is the basis of the OpenOffice.org Linear Solver in Calc. It would certainly be a nice twist of irony if the evil-grasping-Sun-solver Again, not sure what you mean with evil-grasping here? Doesn't Oracle (Sun) hold the copyright and can issue a version with any license of their choice? became exclusive to LibreOffice, but I'll go ahead and spoil the fun: COIN-OR (www.coin-or.org) has a lot of OR code under the less-evil EPL or CPL licenses. Among it: Clp for linear programming, Cbc for integer conditions, and CoinMP, which wraps these in a single shared object with a C interface. I created issue 118160 and attached a simple proof-of-concept patch to use CoinMP instead of lp_solve. From some limited testing, this seems to work very well. Some changes will still be needed for building and packaging, and perhaps some tweaking of solver settings. But the patch shows that replacing lp_solve is clearly a (pardon the pun) solvable problem. Sounds promising, nevertheless. :) ---rony -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Off the records (Ubuntu's LO) ... (Re: Re: Genuine OOo in distributions ? (Re: OOo installation packages for Linux, a few (easy) questions
Hi René, On 07.06.2011 09:56, Rene Engelhard wrote: ... cut ... rene@frodo:~$ find /usr/lib/libreoffice/ -name unoinfo* /usr/lib/libreoffice/program/unoinfo rene@frodo:~$ less /usr/lib/libreoffice/program/unoinfo in Debian, is that what you mean? If yes, then it's interesting why Ubuntu doesn't package it, yes. If not, there's nothing either Debian or Ubuntu broke. Well, Bjoern Michaelsen said so. As it just happens (an Ubuntu machine got X11 troubles after an update to a system which has gnome and kde desktops installed, which was so bad, that I had to reinstall Ubuntu from scratch :( ), this very moment I got a baby-fresh installation of Ubuntu 11.04. unoinfo is there, so what Bjoern said is not true. Having the chance to look at a plain vanilla Ubuntu installation, I checked for the existence of all the necessary jars that get listed by unoinfo java and interestingly unoil.jar is missing! Did a locate unoil.jar after an updatedb, but it is not installed. So this is probably the culprit on Ubuntu (assuming that your Debian installation package has it), breaking the office. BTW, René, where could one download your version of the deb package to test it? ---rony -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Off the records (Ubuntu's LO) ... (Re: Re: Genuine OOo in distributions ? (Re: OOo installation packages for Linux, a few (easy) questions
Hi Bjoern, just saw your e-mail appear now in the list, hence the late answer. Thank you very much for the link! In the meantime further information has become available, thanks to Renés comments, so the installation seems to be (very unfortunate!) intentional (to cripple LO)! :( Regards, ---rony On 06.06.2011 18:07, Bjoern Michaelsen wrote: On Mon, 06 Jun 2011 17:28:24 +0200 rony ro...@openoffice.org wrote: [... lots of hostile ranting ignored ...] And by the way, if you wanted to be constructive, why did you not supply a link to the place for reporting it? If it was easy to find such a place, I would have reported it https://launchpad.net/ubuntu/+source/libreoffice see the report a bug link on the right? Alternatively, use the ubuntu-bug commandline tool. It is not different from any other package at all. Best, Bjoern -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Off the records (Ubuntu's LO) ... (Re: Re: Genuine OOo in distributions ? (Re: OOo installation packages for Linux, a few (easy) questions
On 07.06.2011 12:53, Rene Engelhard wrote: On Tue, Jun 07, 2011 at 12:45:09PM +0200, rony wrote: Thank you very much for the link! In the meantime further information has become available, thanks to Renés comments, so the installation seems to be (very unfortunate!) intentional (to cripple LO)! :( There IS NOTHING CRIPPELD. If packages deviate from the reference packages (OOo or LO), they get crippled, like it or not. (Judging from the e-mails even Debian experts like yourself have not been aware of that done by Ubuntu, nor being able to suggest a resolution right away, just after consulting apt-file, for which I am grateful nevertheless.) Insulting people does not change facts and reality either, but is quite unfortunate as you destroy yourself the personal respect you may have gained for your technical merits in the past. :( ---rony -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Off the records (Ubuntu's LO) ... (Re: Re: Genuine OOo in distributions ? (Re: OOo installation packages for Linux, a few (easy) questions
Hi René, On 07.06.2011 14:07, Rene Engelhard wrote: Insulting people does not change facts and reality either, but is quite You don't? Aha. I see insults from you too. You cripple XYZ. When we don't. (And you say we do that intentionally, which is also a insult) O.K., I take this one on my shoulders, sorry, if you - as a person - took this as an insult, it was never meant to address you. (From your mailings it is clear that you have not removed functionality from the reference OOo or LO packages from the respective Debian package, therefore you have never been meant to be addressed.) The accusation of crippling has been aimed at those who are responsible for removing functionality (= crippling) from the reference package of OOo or LO, which I regard as the standard, the baseline of functionality. Whatever functionality the standard/reference package possesses is what professionals should be able to rely on to be available, if anyone else creates/distributes an OOo or LO package (possibly with added functionality, leaving the base line, i.e. standard/reference package, intact). Regards, ---rony P.S.: In the case of Ubuntu I would expect that they at least advertise very prominently that their OOo/LO distribution is not a standard one, but one that lacks features compared to the standard OOo/LO packages. This way, everyone would be aware of this fact and if the information was given, how to add the missing pieces (sudo apt-get install librefoffice), end-users would become able to upgrade the special Ubuntu OOo/LO to the full package on their own. -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Off the records (Ubuntu's LO) ... (Re: Re: Genuine OOo in distributions ? (Re: OOo installation packages for Linux, a few (easy) questions
Hi Bjoern, On 06.06.2011 12:42, Bjoern Michaelsen wrote: Whatever they did, they probably did what they did with their OOo installation in the past with the effect that using the Java interface from the command line does not work (using their unoinfo-output for Java) ! That has nothing to do with OOo or LibreOffice, it did not work any better with OOo. The root cause is that the bootstrap helper makes quite crazy assumptions about where to find the soffice binary. Debian (and thus Ubuntu) does quite a few changes (for example moving jars around), which the original OOo code does not handle too well. Sorry to correct you: installing the genuine OOo from http://www.OpenOffice.org works. Flawlessly. unoinfo.sh has no role in this at all -- it is not even packaged on Ubuntu. That's one of these amateurish, almost crazy assumptions along the lines: I do not see any use in it, hence let us drop it, it's probably crap anyway. It is almost crazy, because quite a few projects rely on unoinfo supplying the correct CLASSPATH definition for interacting with OOo/LO (the sequence matters), which then simply won't work with the Ubuntu distros. Instead one needs to deinstall LO, remove ~/.libreoffice in home, get the official LO distribution and install it, then things start to work as was the case in the past with OOo. No, you would need to bootstrap with a ClassLoader having a correct resource path. Please, give me a break! Never having seen this being reported against LibreOffice on launchpad, it was assumed as not a serious issue. Who is it? And for what reasons would it assume as not a seriious issue? This is why I qualify such decisions to be amateurish, harming such endeavors enormeously. (Companies affected by the negative outcome of such decisions either turn away or kick out the broken installation.) Whining about it on the mailing list of a different project instead of filing a bug is kind of ridiculous still, isnt it? Whining? This was meant to point out to the OpenOffice.org list that those that have broken OOo for Ubuntu are breaking LO as well! And by the way, if you wanted to be constructive, why did you not supply a link to the place for reporting it? If it was easy to find such a place, I would have reported it (actually I even would report it still as this is a potential problem for quite a few more apps, even if the Ubuntu people are not realizing it, hoping that they are not ignorants). As for my application the workaround is simple: just install the genuine OOo (or LO for that matter) and do not use the broken Ubuntu installation. (Besides, the Ubuntu people broke the user interface with 11.04 bad times, either taking their users hostage for experiments, or having total amateurs in charge for the most important application there exists for an operating system for PC-based end users.) ---rony -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Off the records (Ubuntu's LO) ... (Re: Re: Genuine OOo in distributions ? (Re: [dev] OOo installation packages for Linux, a few (easy) questions
Hi there, totally off the records for this list, but maybe nevertheless interesting/amusing: Ubuntu 11.04 replaced OOo with LibreOffice (LO). Whatever they did, they probably did what they did with their OOo installation in the past with the effect that using the Java interface from the command line does not work (using their unoinfo-output for Java) ! Instead one needs to deinstall LO, remove ~/.libreoffice in home, get the official LO distribution and install it, then things start to work as was the case in the past with OOo. Unbelievable ! ---rony P.S.: Maybe the Ubuntu people do not realize their problem back with OOo and now with LO, when using Java from outside of OOo/LO. -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] OT: What is the current modus of OOo and what is its outlook ?
Hi there, just very curious, short of clear statements on the OOo homepage (looking in the News area): what is the current modus vivendi for OpenOffice.org? Who is developing/releasing it, will it be developed further? Is there a concrete Oracle plan clarifying the future support/development/alignment with OOo (and perhaps LO)? Or is everything in flux at this point in time? (If so when can one expect clarifications?) And another related question: will there be an OOo-Con this year? (If so where - I read something like Hamburg a couple of weeks/monts ago - and when?) Any links that at least explain/clarify parts of these questions at this point in time? TIA, ---rony -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: How to find out whether the installed OOo is 32- or 64-bit
On 11.04.2011 16:16, Joachim Lingner wrote: On 11.04.11 15:35, Stephan Bergmann wrote: On 04/11/11 14:42, rony wrote: On 11.04.2011 13:16, Stephan Bergmann wrote: On 04/11/11 12:24, rony wrote: What I would be after would be to get this information at installation time without any user-interaction (most won't know what would be asked) in a platform independent manner. Something equivalent to a hyptohetic uninfo bitness returning either 32, 64 or 32 64 (if a universal binary). I don't think there is something better than inspecting the binaries with platform specific tools right now. Internally, of course, OOo knows what platform (x86 Linux, x64 Linux, x86 Mac OS X, etc.) it is---this is at least needed when filtering out extension material that is not appropriate for the given platform. (Also, the standard ways to interact with an OOo installation is either via UNO, which abstracts over those platform details, or through extensions, which already support platform differences.) It seems that this is some sort of a chicken and egg problem. E.g. on MacOSX: if one uses Java to query the configuration via UNO, it may be the case that 64-bit Java is used instead of a 32-bit Java when getting in touch with OOo/UNO, which may be a 32-bit (and sometimes in the future) a 64-bit implementation or both (universal binary). Right, when you want to use the OOo's URE to set up a UNO connection to OOo, you easily run into this chicken/egg problem. If no crash is to be expected, what configuration service/path should I use to figure out the architecture/memory model? (Didn't find anything in the schema Setup.xcs nor in Setup-brand.cxu.) Or with other words, is there an XML-file that carries this information, and if so what is its name and element (this would be even easier to analyze without the need to directyl interact with UNO). Jochen (now on CC) should know how OOo's extension manager determines the current platform. The platform is determined ad build time. At runtime one can use then the bootstrap variables $_OS and $_ARCH to get the information. Thank you! How could one access these attributes via Java? Should I open an RFE then for making this information available via configuration files that could be processed without a need to have office running? ---rony -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Further information (Re: Re: MacOSX+OOo3.3: loading a library via Java' System.loadLibrary(...)
Hi there, should I open an issue for this? If so, whom should I assign it to? ---rony On 10.04.2011 13:53, rony wrote: Hi there, testing all kind of combinations, the following behaviour can be observed: * case 1: starting OOo via the Application folder o case 1a (OOo crash): loading a Rexx script via Tools - Macro - Organize Macros - ooRexx then picking a Rexx macro to be edited and then running via the edit window: OOo crashes! [The crash info is appended at the end of this e-mail.] o case 1b (interpreter cannot be loaded): doing a Tools - Macro - Run, picking a Rexx macro yields the error that indicates that the dylib could not be loaded/found. The Java property java.library.path is null! * case 2: starting OOo via a Rexx script from the command line (using the environment of a normal user where CLASSPATH and the like point to the appropriate jars, Java gets set up in its own way (i.e. java.library.path has the value .:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java). o case 2a (success!): immediately loading a Rexx script via Tools - Macro - Organize Macros - ooRexx then picking a Rexx macro to be edited and then running via the edit window works. Thereafter Tools - Macro - Run works with any Rexx script. Creating additional OOo windows allow one to immediately run Rexx scripts successfully! o case 2b (interpreter cannot be loaded): immediately doing a Tools - Macro - Run, picking a Rexx macro yields the error that indicates that the dylib could not be loaded/found. The Java property java.library.path is null! After this has happened, trying to edit a Rexx macro and run it from the edit window does not succeed either (the edit window - a Java JFrame like the one for BeanShell - does not appear, it seems its creation fails silently). Even if opening new OOo instances would not change this behaviour. All in all this seems to be a bug in OOo's scripting framework support on MacOSX resp. the Java environment set up by OOo before executing the scripting framework functionality. Is there anything I could do/try? If not, should I file an issue (and if so, what level and whom to assign to) ? ---rony On 09.04.2011 23:02, rony wrote: Hi there, further debugging reveals, that indeed the error is in java.lang.System.loadLibrary(BSF4ooRexx) java.lang.System.getProperty() at the point of exeption shows that among other things java.library.path is *not* set (returns null), hence the rexx dylib cannot be loaded! Here a few properties queried when the exception is handled and re-thrown: java.library.path=(null) java.class.path=:/SystemLibrary/JavaJavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/javaplugin.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/plugin.jar java.endorsed.dir=(null) java.ext.dirs=/Library/Java/Extensions:/Systems/Library/Java/Extensions:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/ext java.io.tmpdir=(null) sun.boot.library.path and sun.boot.class.path are both set. This seems to be a setup problem in OOo 3.3 for MacOSX in the context of the scripting framework if doing a Tools - Macro - Run! Is there anything I could (try) to do ? TIA, ---rony On 08.04.2011 17:29, Rony G. Flatscher wrote: Hi there, currently debugging a scripting language added to OOo 3.3 via an oxt-extension. The integration into OOo is done using the OOo beanshell programs, but adapted to the scripting language. The scripting language is ooRexx and there is a library that needs to be loaded via Java (using System.loadLibrary(BSF4ooRexx), which on MacOSX is named libBSF4ooRexx.dylib and located in /usr/lib and /usr/lib/java. Now the odd behaviour: 1. If using Tools - Macros - Organize Macros - Edit and running the script off the edit-window, everything works fine. The BSF4ooRexx library is found and used to run the script via the ooRexx interpreter. After doing this once one can execute any ooRexx macro by merely having it run, i.e. Too.ls - Macros - Run or Tools - Macros - Organize Macros - Run. 2. If all instances of OOo have been shut down, and then the same ooRexx script gets executed via Tools - Macros - Run, then an exception is thrown indicating that the library was not found! After such an error, even using the steps described above, would not successfully allow to load the library! o Now closing all instances of OOo and then starting over as described in step # 1 above, everything works again
[dev] Re: How to find out whether the installed OOo is 32- or 64-bit
Dear Stephan and Thomas, thank you for your pointers! On 11.04.2011 09:54, Stephan Bergmann wrote: On 04/09/11 11:27, Rony G. Flatscher wrote: for an installation routine it is necessary to determine whether the installed version of OOo is 32- or 64-bit, as this determines which libraries and configuration should be installed. Is there a way to find that out (currently on Linux, but once MacOSX and/or Windows gain 64-bit versions then the request would be for all platforms)? If so, what would be the correct means? Using the file command on .../program/soffice.bin (Linux) or .../program/soffice (Mac OS X) should mention either 32 or 64 somewhere in its output (which is not specified, so this is with a little luck---also note that at least Mac OS X could also have universal binaries where file would mention both 32 and 64). What I would be after would be to get this information at installation time without any user-interaction (most won't know what would be asked) in a platform independent manner. Something equivalent to a hyptohetic uninfo bitness returning either 32, 64 or 32 64 (if a universal binary). Regards ---rony P.S.: file is usually not installed on Windows, nor the sysinternal utilities like ProcessExplorer. -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: How to find out whether the installed OOo is 32- or 64-bit
On 11.04.2011 13:16, Stephan Bergmann wrote: On 04/11/11 12:24, rony wrote: What I would be after would be to get this information at installation time without any user-interaction (most won't know what would be asked) in a platform independent manner. Something equivalent to a hyptohetic uninfo bitness returning either 32, 64 or 32 64 (if a universal binary). I don't think there is something better than inspecting the binaries with platform specific tools right now. Internally, of course, OOo knows what platform (x86 Linux, x64 Linux, x86 Mac OS X, etc.) it is---this is at least needed when filtering out extension material that is not appropriate for the given platform. (Also, the standard ways to interact with an OOo installation is either via UNO, which abstracts over those platform details, or through extensions, which already support platform differences.) It seems that this is some sort of a chicken and egg problem. E.g. on MacOSX: if one uses Java to query the configuration via UNO, it may be the case that 64-bit Java is used instead of a 32-bit Java when getting in touch with OOo/UNO, which may be a 32-bit (and sometimes in the future) a 64-bit implementation or both (universal binary). If using the wrong bitness combination, i.e. 64-bit Java with 32-bit OOo/UNO (or 32-bit Java with 64-bit OOo/UNO), then an error would occur? (E.g., how about trying it out and if an error comes along one can infer that the wrong bitness was used; but then, if wrong bitnesses are playing a role, is it possible that a crash occurs, which could not be intercepted? ) If no crash is to be expected, what configuration service/path should I use to figure out the architecture/memory model? (Didn't find anything in the schema Setup.xcs nor in Setup-brand.cxu.) Or with other words, is there an XML-file that carries this information, and if so what is its name and element (this would be even easier to analyze without the need to directyl interact with UNO). ---rony -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Further information (Re: Re: MacOSX+OOo3.3: loading a library via Java' System.loadLibrary(...)
Hi there, testing all kind of combinations, the following behaviour can be observed: * case 1: starting OOo via the Application folder o case 1a (OOo crash): loading a Rexx script via Tools - Macro - Organize Macros - ooRexx then picking a Rexx macro to be edited and then running via the edit window: OOo crashes! [The crash info is appended at the end of this e-mail.] o case 1b (interpreter cannot be loaded): doing a Tools - Macro - Run, picking a Rexx macro yields the error that indicates that the dylib could not be loaded/found. The Java property java.library.path is null! * case 2: starting OOo via a Rexx script from the command line (using the environment of a normal user where CLASSPATH and the like point to the appropriate jars, Java gets set up in its own way (i.e. java.library.path has the value .:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java). o case 2a (success!): immediately loading a Rexx script via Tools - Macro - Organize Macros - ooRexx then picking a Rexx macro to be edited and then running via the edit window works. Thereafter Tools - Macro - Run works with any Rexx script. Creating additional OOo windows allow one to immediately run Rexx scripts successfully! o case 2b (interpreter cannot be loaded): immediately doing a Tools - Macro - Run, picking a Rexx macro yields the error that indicates that the dylib could not be loaded/found. The Java property java.library.path is null! After this has happened, trying to edit a Rexx macro and run it from the edit window does not succeed either (the edit window - a Java JFrame like the one for BeanShell - does not appear, it seems its creation fails silently). Even if opening new OOo instances would not change this behaviour. All in all this seems to be a bug in OOo's scripting framework support on MacOSX resp. the Java environment set up by OOo before executing the scripting framework functionality. Is there anything I could do/try? If not, should I file an issue (and if so, what level and whom to assign to) ? ---rony On 09.04.2011 23:02, rony wrote: Hi there, further debugging reveals, that indeed the error is in java.lang.System.loadLibrary(BSF4ooRexx) java.lang.System.getProperty() at the point of exeption shows that among other things java.library.path is *not* set (returns null), hence the rexx dylib cannot be loaded! Here a few properties queried when the exception is handled and re-thrown: java.library.path=(null) java.class.path=:/SystemLibrary/JavaJavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/javaplugin.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/plugin.jar java.endorsed.dir=(null) java.ext.dirs=/Library/Java/Extensions:/Systems/Library/Java/Extensions:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/ext java.io.tmpdir=(null) sun.boot.library.path and sun.boot.class.path are both set. This seems to be a setup problem in OOo 3.3 for MacOSX in the context of the scripting framework if doing a Tools - Macro - Run! Is there anything I could (try) to do ? TIA, ---rony On 08.04.2011 17:29, Rony G. Flatscher wrote: Hi there, currently debugging a scripting language added to OOo 3.3 via an oxt-extension. The integration into OOo is done using the OOo beanshell programs, but adapted to the scripting language. The scripting language is ooRexx and there is a library that needs to be loaded via Java (using System.loadLibrary(BSF4ooRexx), which on MacOSX is named libBSF4ooRexx.dylib and located in /usr/lib and /usr/lib/java. Now the odd behaviour: 1. If using Tools - Macros - Organize Macros - Edit and running the script off the edit-window, everything works fine. The BSF4ooRexx library is found and used to run the script via the ooRexx interpreter. After doing this once one can execute any ooRexx macro by merely having it run, i.e. Too.ls - Macros - Run or Tools - Macros - Organize Macros - Run. 2. If all instances of OOo have been shut down, and then the same ooRexx script gets executed via Tools - Macros - Run, then an exception is thrown indicating that the library was not found! After such an error, even using the steps described above, would not successfully allow to load the library! o Now closing all instances of OOo and then starting over as described in step # 1 above, everything works again as described above. Going through the Java sourcecode that gets employed, the same steps are undertaken to load the ooRexx scripting engine. I.e
[dev] How to find out whether the installed OOo is 32- or 64-bit
Hi there, for an installation routine it is necessary to determine whether the installed version of OOo is 32- or 64-bit, as this determines which libraries and configuration should be installed. Is there a way to find that out (currently on Linux, but once MacOSX and/or Windows gain 64-bit versions then the request would be for all platforms)? If so, what would be the correct means? TIA ---rony -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: MacOSX+OOo3.3: loading a library via Java' System.loadLibrary(...)
Hi there, further debugging reveals, that indeed the error is in java.lang.System.loadLibrary(BSF4ooRexx) java.lang.System.getProperty() at the point of exeption shows that among other things java.library.path is *not* set (returns null), hence the rexx dylib cannot be loaded! Here a few properties queried when the exception is handled and re-thrown: java.library.path=(null) java.class.path=:/SystemLibrary/JavaJavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/javaplugin.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/plugin.jar java.endorsed.dir=(null) java.ext.dirs=/Library/Java/Extensions:/Systems/Library/Java/Extensions:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/ext java.io.tmpdir=(null) sun.boot.library.path and sun.boot.class.path are both set. This seems to be a setup problem in OOo 3.3 for MacOSX in the context of the scripting framework if doing a Tools - Macro - Run! Is there anything I could (try) to do ? TIA, ---rony On 08.04.2011 17:29, Rony G. Flatscher wrote: Hi there, currently debugging a scripting language added to OOo 3.3 via an oxt-extension. The integration into OOo is done using the OOo beanshell programs, but adapted to the scripting language. The scripting language is ooRexx and there is a library that needs to be loaded via Java (using System.loadLibrary(BSF4ooRexx), which on MacOSX is named libBSF4ooRexx.dylib and located in /usr/lib and /usr/lib/java. Now the odd behaviour: 1. If using Tools - Macros - Organize Macros - Edit and running the script off the edit-window, everything works fine. The BSF4ooRexx library is found and used to run the script via the ooRexx interpreter. After doing this once one can execute any ooRexx macro by merely having it run, i.e. Too.ls - Macros - Run or Tools - Macros - Organize Macros - Run. 2. If all instances of OOo have been shut down, and then the same ooRexx script gets executed via Tools - Macros - Run, then an exception is thrown indicating that the library was not found! After such an error, even using the steps described above, would not successfully allow to load the library! o Now closing all instances of OOo and then starting over as described in step # 1 above, everything works again as described above. Going through the Java sourcecode that gets employed, the same steps are undertaken to load the ooRexx scripting engine. I.e. ScriptProviderForooRexx.java and ScriptSourceModel.java; the sourcecode of these files could be seen via the web using http://bsf4oorexx.svn.sourceforge.net/viewvc/bsf4oorexx/trunk/com/sun/star/script/framework/provider/oorexx/ (just click on the filename and then choose view). It seems that success and unsuccess is not caused by the scripting framework support, but seems to be linked to how OOo instantiates the ooRexx scripting framework? * Like, if the OOo dispatch interface is attempting to loading the scripting language it fails (and makes subsequent attempts to fail as well), * whereas if using the scripting framework editor to load a script first thing and run it off the editor in the first OOo session, then everything works (also subsequent dispatches). Does anyone have any ideas what might cause such a phenomenon? Any ideas highly welcome! TIA, ---rony -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] MacOSX+OOo3.3: loading a library via Java' System.loadLibrary(...)
Hi there, currently debugging a scripting language added to OOo 3.3 via an oxt-extension. The integration into OOo is done using the OOo beanshell programs, but adapted to the scripting language. The scripting language is ooRexx and there is a library that needs to be loaded via Java (using System.loadLibrary(BSF4ooRexx), which on MacOSX is named libBSF4ooRexx.dylib and located in /usr/lib and /usr/lib/java. Now the odd behaviour: 1. If using Tools - Macros - Organize Macros - Edit and running the script off the edit-window, everything works fine. The BSF4ooRexx library is found and used to run the script via the ooRexx interpreter. After doing this once one can execute any ooRexx macro by merely having it run, i.e. Too.ls - Macros - Run or Tools - Macros - Organize Macros - Run. 2. If all instances of OOo have been shut down, and then the same ooRexx script gets executed via Tools - Macros - Run, then an exception is thrown indicating that the library was not found! After such an error, even using the steps described above, would not successfully allow to load the library! o Now closing all instances of OOo and then starting over as described in step # 1 above, everything works again as described above. Going through the Java sourcecode that gets employed, the same steps are undertaken to load the ooRexx scripting engine. I.e. ScriptProviderForooRexx.java and ScriptSourceModel.java; the sourcecode of these files could be seen via the web using http://bsf4oorexx.svn.sourceforge.net/viewvc/bsf4oorexx/trunk/com/sun/star/script/framework/provider/oorexx/ (just click on the filename and then choose view). It seems that success and unsuccess is not caused by the scripting framework support, but seems to be linked to how OOo instantiates the ooRexx scripting framework? * Like, if the OOo dispatch interface is attempting to loading the scripting language it fails (and makes subsequent attempts to fail as well), * whereas if using the scripting framework editor to load a script first thing and run it off the editor in the first OOo session, then everything works (also subsequent dispatches). Does anyone have any ideas what might cause such a phenomenon? Any ideas highly welcome! TIA, ---rony -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
Re: [dev] MacOSX: ScirptingFramework's Edit ...
Hi Christian, On 15.02.2011 22:30, Christian Lohmaier wrote: Hi Rony, *, On Tue, Feb 15, 2011 at 9:49 PM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: in the meantime it has become possible to install an oxt-package that adds ooRexx as a new macro language to OOo on the MacOSX. [...] However choosing Edit does not work, nothing happens. Edit should invoke a JFrame editor which allows one to look over a macro, http://qa.openoffice.org/issues/show_bug.cgi?id=92926 *UNBELIEVABLLE !!!* This is just unbelievable, having P2 priority and no one really fixes this for years it seems? How can that be possible?? Actually, this should be a showstopper for OOo 3.4 at level P1, seriously! ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Ad ooRexx-Integration with OOo (Re: [dev] Re: MacOSX: ScirptingFramework's Edit ...
Hi Alex, On 16.02.2011 10:46, Alexander Thurgood wrote: Le 15/02/11 21:49, Rony G. Flatscher a écrit : Hi Rony, in the meantime it has become possible to install an oxt-package that adds ooRexx as a new macro language to OOo on the MacOSX. The tested ooRexx scripts run correctly, it is possible to create new macros (Tools - Macros - Organize Macros - ooRexx, then Run or Create, which creates a new ooRexx macro from the template in the oxt-package). I would be interested in testing this - any hint as to where I might get the extension ? Haven't worked with REXX in a while though. Sure: * First get ooRexx 4.1 for your platfrom from http://www.oorexx.org/download.html (it is fully compatible with REXX, but adds OO-features, many concepts drawn/applied from Smalltalk in more user-friendly way), * then get BSF4ooRexx from http://wi.wu.ac.at:8002/rgf/rexx/bsf4oorexx/current/, which makes all of the strictly typed, case-dependent Java available as if it was the typeless, case-independent ooRexx. Currently the port of BSF4ooRexx (which includes the OOo integration) for MacOSX is in the works. The 32- and 64-bit versions work on MacOSX, the OOo-support is now being developed (it seems it is mostly dependent on the correct environment settings for Java). Unfortunately, it seems according to Christian's URL to the respective issue http://qa.openoffice.org/issues/show_bug.cgi?id=92926, that awt/swing on MacOSX is currently not possible, because OOo does - against Apple's documentation dating back to 2005 ! - not load the JVM in a separate thread. Hopefully, this is understood as a true showstopper for OOo 3.4 by the developers, such that this defect gets fixed on MacOSX as soon as possible! --- If you want to peek around what becomes possible with ooRexx in the context of OOo, then just look over some work of some of my students at http://wi.wu.ac.at:8002/rgf/diplomarbeiten/, which gest updated once or twice a year. There are numerous seminar-papers, Master-thesis and Bachelor-thesis from Business Administration students who use this very integration for driving/explaining OpenOffice programming (many of these students are not professional programmers, but the kind of end-user programmers, so it is astonishing, what they become able to achieve with the right, ie. easy, scripting language). Regards, ---rony P.S.: Will write a text-book on ooRexx and one about BSF4ooRexx in the next months to come (a long-standing requests from students).
Re: [dev] Re: MacOSX: ScirptingFramework's Edit ...
On 16.02.2011 12:21, Alexander Thurgood wrote: Le 16/02/11 11:57, rony a écrit : Hi Rony, http://qa.openoffice.org/issues/show_bug.cgi?id=92926 *UNBELIEVABLLE !!!* This is just unbelievable, having P2 priority and no one really fixes this for years it seems? How can that be possible?? Oh, and getting system python to work on Mac, instead of having to bundle another version within OOo, have you looked at that one yet ? ;-) How long has that been around ? 4 or 5 years ?? Always boils down to developer resources in the end. Yes, that's always the best excuse, if those with the powers don't appreciate something. It seems that no one at Oracle/Sun's management realizes the importance of scripts/macros. E.g. OOo's scripting framework is written in Java, but to this very day they do not take advantage of that and add JSR-223 support to it. JSR-223 support means, that all scripting languages that work (available starting with Java 6, or from the Apache Software Foundation as BSF 3.0 which can be deployed for Java 1.4 and up) with Java, would be immediately be available for OOo! It would be possible to write a single editor which would edit and run all JSR-223 scripts out of the box. Unbelievably, this has not been done to this very day. If there was JSR-223 support in OOo's scripting framework then one could use Jython as well. (Of course the OOo language binding of Python would make pure Python desirable.) Again, if strategic, tactical thoughts would play a role in this important context of OOo scripting too, then such changes/additions would have been implemented long ago. My hope is that eventually the forces in power wake up as long as there is time... ;) ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Ad ooRexx-Integration with OOo (Re: [dev] Re: MacOSX: ScirptingFramework's Edit ...
Hi Alex, On 16.02.2011 14:47, Alexander Thurgood wrote: Le 16/02/11 12:07, rony a écrit : Thanks for the links, will check them out. As it happens, the ports mechanism on Mac has oorexx so I have done installed it through the ports system. Yes, but be aware that the version there is still 4.0.1. Currently, there is no official version for 4.1.0 for MacOSX, although one can build the interpreter from the oorexx svn's main/releases/4.1.0, though I would suggest to build it from main/branches/4.1 which incorporates a fix for a bug, that I uncovered while testing the port of ooRexx 4.1.0 and BSF4ooRexx to MacOSX. The port of BSF4ooRexx to MacOSX is not yet publically available, if you want to experiment with it, please drop me a note and I upload it such that you could download it. Currently, the support for OOo is developed/tested, which basically means setting up the environment for Java correctly. There are two students who have taken on the task to create (mostly GUI-based) installers for BSF4ooRexx for various platforms, including MacOSX. Probably, by the end of March an official release can be published (hoping that OOo 3.4 had fixed the Java-bug, such that the Editing of scripts would work on MacOSX). Currently the port of BSF4ooRexx (which includes the OOo integration) for MacOSX is in the works. The 32- and 64-bit versions work on MacOSX, the OOo-support is now being developed (it seems it is mostly dependent on the correct environment settings for Java). Hmmm, I was wondering whether only the 32bit version of BSF4ooRexx would work with OOo because it is only compiles as 32bit on the Mac at the moment as far as I know ? Yes, you must use the 32-bit version of ooRexx as OOo is only available for 32-bit on MacOSX. BSF4ooRexx itself will be able to serve both, 32- and 64-bit ooRexx and Java. Unfortunately, it seems according to Christian's URL to the respective issue http://qa.openoffice.org/issues/show_bug.cgi?id=92926, that awt/swing on MacOSX is currently not possible, because OOo does - against Apple's documentation dating back to 2005 ! - not load the JVM in a separate thread. Hopefully, this is understood as a true showstopper for OOo 3.4 by the developers, such that this defect gets fixed on MacOSX as soon as possible! Until recently, OOo was still using an outdated and deprecated mechanism for finding the JVM in the first place, which caused it to not recognise the presence of Java on the system, as the automatic update by Apple to Java 1.6.0_22 showed. That has since been fixed, but the issue had been notified in advance by Apple, and the NeoOffice project had taken the necessary steps to avoid the problem, whereas it was only addressed on OOo when Mac users started filing bug reports that they couldn't get OOo 3.3 RCxx to function properly on their systems anymore, due to the huge dependencies on having a recognised JVM. It is symptomatic of the resource allocation problem IMHO and a shame, but there you go. This should not be the case, as full and professional support for MacOSX is important for that segment to be able to fully accept OOo. (And, hey, this is mainly Sun/Oracle, the inventor of Java, so that should not be a problem at all!) Anyway, I will check out the stuff on the Wien server - a book would be a real plus !!! :-)) Will report, once the first book is done (hopefully by the end of this summer). ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] MacOSX+OOo3.3+Java: howto setup ?
Hi there, trying to figure out the setup needs for OOo 3.3 on MacOSX, if wishing to use Java from the commandline to bootstrap and work with OOo 3.3. Adding the paths to all of the OOo 3.3. jar-files to CLASSPATH does not yield success, as openoffice is not found. What is the correct/designed setup if one wishes to achieve that? Is there a readme or wiki somewhere describing the necessary environment? ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] MacOSX+OOo3.3+Java: howto setup ?
On 15.02.2011 13:31, Stephan Bergmann wrote: On 02/15/11 11:54, Rony G. Flatscher wrote: trying to figure out the setup needs for OOo 3.3 on MacOSX, if wishing to use Java from the commandline to bootstrap and work with OOo 3.3. http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/Transparent_Use_of_Office_UNO_Components should be what you are looking for. Not sure how well the automatic detection of an OOo installation part works on Mac OS X, but you can always do that manually via the com.sun.star.lib.loader.unopath Java system property. Stephan, thank you very much for your link! Unfortunately, it did not help. Scenario: the program uses Java to load com.sun.star.comp.helper.Bootstrap, which is found. Excercising then the bootstrap method yields the following stack trace: sch... UNEXPECTED error, cannot bootstrap and/or retrieve singletons! *com.sun.star.comp.helper.BootstrapException: no office executable found!* at com.sun.star.comp.helper.Bootstrap.bootstrap(Bootstrap.java:243) at org.oorexx.uno.RgfReflectUNO.setContext(RgfReflectUNO.java:368) at org.oorexx.uno.RgfReflectUNO.findInterfaceWithMember(RgfReflectUNO.java:2387) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.rexxla.bsf.engines.rexx.RexxAndJava.invokeMethod(RexxAndJava.java:4826) at org.rexxla.bsf.engines.rexx.RexxAndJava.javaCallBSF(RexxAndJava.java:3590) at org.rexxla.bsf.engines.rexx.RexxAndJava.jniRexxRunProgram(Native Method) at org.rexxla.bsf.engines.rexx.RexxEngine.apply(RexxEngine.java:833) at org.rexxla.bsf.RexxDispatcher.main(RexxDispatcher.java:134) RexxDispatcher.java: Throwable of type 'org.rexxla.bsf.engines.rexx.RexxException' thrown while invoking Rexx: getLocalizedMessage(): [BSF4ooRexx/routine/jniRexxRunProgram(), error 9: 1805 *-* return uno.wrap( .uno~rgfReflectUNO~findInterfaceWithMember( o, name, bReturnString, howMany, .uno~bExtendSearch) ) Error 40 running /usr/bin/UNO.CLS line 1805: Incorrect call to routine Error 40.900: BSF4ooRexx/routine/BSF(), error 3: Java exception occurred: [org.apache.bsf.BSFException: /// Java-exception (RexxAndJava) occurred: [java.lang.reflect.InvocationTargetException], getCause(): [java.lang.NullPointerException] \\\ BSF4ooRexx subfunction invoke: object 'java.lang.Class@196c1b0' - method [FINDINTERFACEWITHMEMBER], method not found or error (exception) executing method!]] Now according to the description in the wiki your link points to, I added the path to soffice to PATH: PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/Applications/OpenOffice.org.app/Contents/program doing which soffice yields successfully: /Applications/OpenOffice.org.app/Contents/program/soffice ... and because it did not change the behaviour added a UNO_PATH environment variable: UNO_PATH=/Applications/OpenOffice.org.app/Contents/program The jar-files seem to have been found (as it is possible to load and use the com.sun.star.comp.helper.Bootstrap Java class. Here the shell script to set the environment: export PATH=$PATH:/Applications/OpenOffice.org.app/Contents/program OOOJAVA=/Applications/OpenOffice.org.app/Contents/basis-link/ure-link/share/java export CLASSPATH=$CLASSPATH:$OOOJAVA/juh.jar:$OOOJAVA/jurt.jar:$OOOJAVA/ridl.jar:$OOOJAVA/java_uno.jar:$OOOJAVA/unoloader.jar export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/Applications/OpenOffice.org.app/Contents/basis-link/ure-link/lib This is about running a program that works on Windows and various Linuxes. As MacOSX has quite a few specific needs applications reside in a directory (shown as a single file) under /Applications. Looking into OpenOffice.org.app the structure includes symbolic links (looking like criss-cross, but within the OpenOffice.org.app subdirectories). Maybe there is some little piece of information missing, to get com.sun.star.comp.helper.Bootstrap's bootstrap method to find its executable? Would you have any ideas, pointers, links that I could experiment with? TIA ---rony P.S.: here's the uname -a output in case it matters (MacOSX 10.6.6): Darwin abt-wi-031.wu-wien.ac.at 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386
Re: [dev] MacOSX+OOo3.3+Java: howto setup ?
In the meantime I experimented with the Java system variable com.sun.star.lib.loader.unopath to no avail. The most important settings used were: propName=com.sun.star.lib.loader.unopath propValue=/Applications/OpenOffice.org.app/Contents/MacOS propValue=/Applications/OpenOffice.org.app/Contents/program propValue=/Applications/OpenOffice.org.app propValue=/Applications/OpenOffice.org.app/Contents/basis-link/program propValue=/Applications/OpenOffice.org.app/Contents/basis-link ---rony On 15.02.2011 16:27, rony wrote: On 15.02.2011 13:31, Stephan Bergmann wrote: On 02/15/11 11:54, Rony G. Flatscher wrote: trying to figure out the setup needs for OOo 3.3 on MacOSX, if wishing to use Java from the commandline to bootstrap and work with OOo 3.3. http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/Transparent_Use_of_Office_UNO_Components should be what you are looking for. Not sure how well the automatic detection of an OOo installation part works on Mac OS X, but you can always do that manually via the com.sun.star.lib.loader.unopath Java system property. Stephan, thank you very much for your link! Unfortunately, it did not help. Scenario: the program uses Java to load com.sun.star.comp.helper.Bootstrap, which is found. Excercising then the bootstrap method yields the following stack trace: sch... UNEXPECTED error, cannot bootstrap and/or retrieve singletons! *com.sun.star.comp.helper.BootstrapException: no office executable found!* at com.sun.star.comp.helper.Bootstrap.bootstrap(Bootstrap.java:243) at org.oorexx.uno.RgfReflectUNO.setContext(RgfReflectUNO.java:368) at org.oorexx.uno.RgfReflectUNO.findInterfaceWithMember(RgfReflectUNO.java:2387) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.rexxla.bsf.engines.rexx.RexxAndJava.invokeMethod(RexxAndJava.java:4826) at org.rexxla.bsf.engines.rexx.RexxAndJava.javaCallBSF(RexxAndJava.java:3590) at org.rexxla.bsf.engines.rexx.RexxAndJava.jniRexxRunProgram(Native Method) at org.rexxla.bsf.engines.rexx.RexxEngine.apply(RexxEngine.java:833) at org.rexxla.bsf.RexxDispatcher.main(RexxDispatcher.java:134) RexxDispatcher.java: Throwable of type 'org.rexxla.bsf.engines.rexx.RexxException' thrown while invoking Rexx: getLocalizedMessage(): [BSF4ooRexx/routine/jniRexxRunProgram(), error 9: 1805 *-* return uno.wrap( .uno~rgfReflectUNO~findInterfaceWithMember( o, name, bReturnString, howMany, .uno~bExtendSearch) ) Error 40 running /usr/bin/UNO.CLS line 1805: Incorrect call to routine Error 40.900: BSF4ooRexx/routine/BSF(), error 3: Java exception occurred: [org.apache.bsf.BSFException: /// Java-exception (RexxAndJava) occurred: [java.lang.reflect.InvocationTargetException], getCause(): [java.lang.NullPointerException] \\\ BSF4ooRexx subfunction invoke: object 'java.lang.Class@196c1b0' - method [FINDINTERFACEWITHMEMBER], method not found or error (exception) executing method!]] Now according to the description in the wiki your link points to, I added the path to soffice to PATH: PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/Applications/OpenOffice.org.app/Contents/program doing which soffice yields successfully: /Applications/OpenOffice.org.app/Contents/program/soffice ... and because it did not change the behaviour added a UNO_PATH environment variable: UNO_PATH=/Applications/OpenOffice.org.app/Contents/program The jar-files seem to have been found (as it is possible to load and use the com.sun.star.comp.helper.Bootstrap Java class. Here the shell script to set the environment: export PATH=$PATH:/Applications/OpenOffice.org.app/Contents/program OOOJAVA=/Applications/OpenOffice.org.app/Contents/basis-link/ure-link/share/java export CLASSPATH=$CLASSPATH:$OOOJAVA/juh.jar:$OOOJAVA/jurt.jar:$OOOJAVA/ridl.jar:$OOOJAVA/java_uno.jar:$OOOJAVA/unoloader.jar export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/Applications/OpenOffice.org.app/Contents/basis-link/ure-link/lib This is about running a program that works on Windows and various Linuxes. As MacOSX has quite a few specific needs applications reside in a directory (shown as a single file) under /Applications. Looking into OpenOffice.org.app the structure includes symbolic links (looking like criss-cross, but within the OpenOffice.org.app subdirectories). Maybe there is some little piece of information missing, to get com.sun.star.comp.helper.Bootstrap's bootstrap method to find its
[dev] Partially solved (Re: [dev] MacOSX+OOo3.3+Java: howto setup ?
Partially solved! The CLASSPATH-environment variable must also have the directory listed, in which soffice resides. The shell script to create the needed environment on Apple looks like: UNO_PATH=/Applications/OpenOffice.org.app/Contents/program export PATH=$PATH:$UNO_PATH OOOJAVA=/Applications/OpenOffice.org.app/Contents/basis-link/ure-link/share/java export CLASSPATH=$CLASSPATH:*$UNO_PATH*:$OOOJAVA/juh.jar:$OOOJAVA/jurt.jar:$OOOJAVA/ridl.jar:$OOOJAVA/java_uno.jar:$OOOJAVA/unoloader.jar It is now possible to start OOo employing the OOo Java APIs. --- There is one problem (not occurring on Windows and Linux) left, which maybe someone has an idea about: [java.lang.reflect.InvocationTargetException], getCause(): [com.sun.star.lang.DisposedException: com.sun.star.uno.RuntimeException: java.lang.ClassNotFoundException: com.sun.star.frame.XDesktop] \\\ BSF4ooRexx subfunction invoke: object 'java.lang.Class@1db699b' - method [FINDINTERFACEWITHMEMBER], method not found or error (exception) executing method!]] The flow is as follows: * after bootstrapping the received context is stored in a Java class which uses the context later for reflection, * then the com.sun.star.frame.Desktop service object is created with that context, * then the XDesktop interface is queried using reflection; this is where the error occurs: o unwrapping the wrapped exceptions (with getCause()) yields the string: + com.sun.star.lang.DisposedException: com.sun.star.uno.RuntimeException: java.lang.ClassNotFoundException: com.sun.star.frame.XDesktop If it is a disposed exception, then the cached context or the service object are candidates for that to occur. However, on Windows and Linux this does not happen as there are (global) references to these Java objects which should inhibit any disposals. TIA, ---rony On 15.02.2011 16:27, rony wrote: On 15.02.2011 13:31, Stephan Bergmann wrote: On 02/15/11 11:54, Rony G. Flatscher wrote: trying to figure out the setup needs for OOo 3.3 on MacOSX, if wishing to use Java from the commandline to bootstrap and work with OOo 3.3. http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/Transparent_Use_of_Office_UNO_Components should be what you are looking for. Not sure how well the automatic detection of an OOo installation part works on Mac OS X, but you can always do that manually via the com.sun.star.lib.loader.unopath Java system property. Stephan, thank you very much for your link! Unfortunately, it did not help. Scenario: the program uses Java to load com.sun.star.comp.helper.Bootstrap, which is found. Excercising then the bootstrap method yields the following stack trace: sch... UNEXPECTED error, cannot bootstrap and/or retrieve singletons! *com.sun.star.comp.helper.BootstrapException: no office executable found!* at com.sun.star.comp.helper.Bootstrap.bootstrap(Bootstrap.java:243) at org.oorexx.uno.RgfReflectUNO.setContext(RgfReflectUNO.java:368) at org.oorexx.uno.RgfReflectUNO.findInterfaceWithMember(RgfReflectUNO.java:2387) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.rexxla.bsf.engines.rexx.RexxAndJava.invokeMethod(RexxAndJava.java:4826) at org.rexxla.bsf.engines.rexx.RexxAndJava.javaCallBSF(RexxAndJava.java:3590) at org.rexxla.bsf.engines.rexx.RexxAndJava.jniRexxRunProgram(Native Method) at org.rexxla.bsf.engines.rexx.RexxEngine.apply(RexxEngine.java:833) at org.rexxla.bsf.RexxDispatcher.main(RexxDispatcher.java:134) RexxDispatcher.java: Throwable of type 'org.rexxla.bsf.engines.rexx.RexxException' thrown while invoking Rexx: getLocalizedMessage(): [BSF4ooRexx/routine/jniRexxRunProgram(), error 9: 1805 *-* return uno.wrap( .uno~rgfReflectUNO~findInterfaceWithMember( o, name, bReturnString, howMany, .uno~bExtendSearch) ) Error 40 running /usr/bin/UNO.CLS line 1805: Incorrect call to routine Error 40.900: BSF4ooRexx/routine/BSF(), error 3: Java exception occurred: [org.apache.bsf.BSFException: /// Java-exception (RexxAndJava) occurred: [java.lang.reflect.InvocationTargetException], getCause(): [java.lang.NullPointerException] \\\ BSF4ooRexx subfunction invoke: object 'java.lang.Class@196c1b0' - method [FINDINTERFACEWITHMEMBER], method not found or error (exception) executing method!]] Now according to the description in the wiki your link points to, I added the path to soffice to PATH: PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr
[dev] Solved (Re: [dev] Partially solved (Re: [dev] MacOSX+OOo3.3+Java: howto setup ?
Using the following shell script to set up the CLASSPATH environment variable on MacOSX solved the problem finally: UNO_PATH=/Applications/OpenOffice.org.app/Contents/program OOOJAVA=/Applications/OpenOffice.org.app/Contents/basis-link/ure-link/share/java export CLASSPATH=$CLASSPATH:$UNO_PATH:$OOOJAVA/juh.jar:$OOOJAVA/jurt.jar:$OOOJAVA/ridl.jar export CLASSPATH=$CLASSPATH:/Applications/OpenOffice.org.app/Contents/basis-link/program/classes/unoil.jar ---rony
[dev] MacOSX: ScirptingFramework's Edit ...
Hi there, in the meantime it has become possible to install an oxt-package that adds ooRexx as a new macro language to OOo on the MacOSX. The tested ooRexx scripts run correctly, it is possible to create new macros (Tools - Macros - Organize Macros - ooRexx, then Run or Create, which creates a new ooRexx macro from the template in the oxt-package). However choosing Edit does not work, nothing happens. Edit should invoke a JFrame editor which allows one to look over a macro, change it and run it from the editor window. The same oxt-package works unchanged with the Edit-functionality on Windows and Linux. Any ideas what could be the reason? Where would I find any logs on MacOSX relating to such a problem (where is OOo logging errors to on that platform)? ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] OpenOffice sample TextReplace throws BootstrapException
On 13.12.2010 10:06, Jürgen Schmidt wrote: On 12/13/10 9:35 AM, Stephan Bergmann wrote: On 12/11/10 16:52, Ariel Constenla-Haile wrote: If you are using version 3.4... are you one of the developers? well I don't dare to call myself that, so let's say I'm a community contributor. What you do is truly great, btw. Thanks a lot Ariel. +1 ++1 ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Ubuntu desktop 10.4.1 de: Cannot start OOo, because
Hi Stephan, On 14.09.2010 14:55, Stephan Bergmann wrote: On 09/14/10 08:21, rony wrote: The logfile (and a text-file giving information on the system) can be found at:http://wi.wu.ac.at/rgf/tmp/OOo/. One odd thing in http://wi.wu.ac.at/rgf/tmp/OOo/ubuntu%5fdesktop%5f1004%5fsoffice%2estrace%2elog is that all attempts to access the OOo per-user data in /home/administrator/.openoffice.org/3/user fail with EACCESS (Permission denied). It looks like user administrator has no rights to access his home directory (/home/administrator). What is the output of ls -alF /home/administrator, ls -alF /home/administrator/.openoffice.org, ls -alF /home/administrator/.openoffice.org/3, and ls -alF /home/administrator/.openoffice.org/3/user? Could get at the machine yesterday night, here the results: administra...@flatscher:~$ ls -alF /home/administrator/ hadm.txt insgesamt 1372 drwxr-xr-x 33 administrator administrator4096 2010-09-14 22:13 ./ drwxr-xr-x 3 root root 4096 2010-09-06 09:14 ../ -rw--- 1 root root 263 2010-09-06 09:34 .bash_history -rw-r--r-- 1 administrator administrator 220 2010-09-06 09:14 .bash_logout -rw-r--r-- 1 administrator administrator3103 2010-09-12 18:34 .bashrc drwxr-xr-x 2 administrator administrator4096 2010-09-06 09:20 Bilder/ drwx-- 5 administrator administrator4096 2010-09-14 22:09 .cache/ drwx-- 3 administrator administrator4096 2010-09-06 09:20 .compiz/ drwxr-xr-x 6 administrator administrator4096 2010-09-06 09:24 .config/ drwx-- 3 administrator administrator4096 2010-09-06 09:20 .dbus/ drwxr-xr-x 2 administrator administrator4096 2010-09-06 11:19 Desktop/ -rw-r--r-- 1 administrator administrator 41 2010-09-14 22:09 .dmrc drwxr-xr-x 2 administrator administrator4096 2010-09-06 09:20 Dokumente/ drwxr-xr-x 3 administrator administrator4096 2010-09-06 09:57 Downloads/ -rw--- 1 administrator administrator 16 2010-09-06 09:20 .esd_auth drwxr-xr-x 3 administrator administrator4096 2010-09-06 11:07 .evolution/ -rw-r--r-- 1 administrator administrator 179 2010-09-06 09:14 examples.desktop drwxr-xr-x 2 administrator administrator4096 2010-09-06 11:16 .fontconfig/ drwx-- 4 administrator administrator4096 2010-09-14 22:09 .gconf/ drwx-- 2 administrator administrator4096 2010-09-14 22:11 .gconfd/ -rw-r- 1 administrator administrator 0 2010-09-12 18:25 .gksu.lock drwx-- 8 administrator administrator4096 2010-09-13 23:17 .gnome2/ drwx-- 2 administrator administrator4096 2010-09-06 09:20 .gnome2_private/ drwxr-xr-x 2 administrator administrator4096 2010-09-06 09:20 .gstreamer-0.10/ -rw-r--r-- 1 administrator administrator 175 2010-09-14 22:09 .gtk-bookmarks dr-x-- 2 administrator administrator 0 2010-09-14 22:09 .gvfs/ -rw-r--r-- 1 administrator administrator 0 2010-09-14 22:13 hadm.txt drwxr- 2 administrator administrator4096 2010-09-12 19:14 .hplip/ -rw--- 1 administrator administrator4290 2010-09-14 22:09 .ICEauthority drwx-- 3 administrator administrator4096 2010-09-06 09:20 .local/ drwx-- 2 root root 4096 2010-09-06 09:28 .mc/ drwx-- 4 administrator administrator4096 2010-09-06 09:54 .mozilla/ drwxr-xr-x 2 administrator administrator4096 2010-09-06 09:20 Musik/ drwxr-xr-x 2 administrator administrator4096 2010-09-06 09:20 .nautilus/ drwxr-xr-x 2 administrator administrator4096 2010-09-06 09:20 Öffentlich/ drwxr-xr-x 3 root root 4096 2010-09-06 10:04 .openoffice.org/ -rw-r--r-- 1 administrator administrator 37 2010-09-12 19:14 .printer-groups.xml -rw-r--r-- 1 administrator administrator 675 2010-09-06 09:14 .profile drwx-- 2 administrator administrator4096 2010-09-14 22:09 .pulse/ -rw--- 1 administrator administrator 256 2010-09-06 09:20 .pulse-cookie -rw--- 1 administrator administrator2202 2010-09-13 23:17 .recently-used.xbel drwx-- 2 administrator administrator4096 2010-09-06 11:19 .ssh/ -rw-r--r-- 1 administrator administrator 0 2010-09-06 09:24 .sudo_as_admin_successful drwx-- 3 administrator administrator4096 2010-09-06 09:20 .thumbnails/ -rw-r--r-- 1 administrator administrator 1201596 2010-09-13 23:13 ubuntu_desktop_1004_soffice.strace.log -rw-r--r-- 1 administrator administrator 550 2010-09-13 23:17 ubuntu_desktop_1004_soffice.txt drwx-- 2 administrator administrator4096 2010-09-06 09:24 .update-notifier/ drwxr-xr-x 2 administrator administrator4096 2010-09-06 09:20 Videos/ -rw--- 1 root root 1525 2010-09-06 09:34 .viminfo
Re: [dev] Ubuntu desktop 10.4.1 de: Cannot start OOo, because
Dear Stephan, On 15.09.2010 11:51, Stephan Bergmann wrote: On 09/15/10 08:12, rony wrote: administra...@flatscher:~$ ls -alF /home/administrator/.openoffice.org/ hadm-ooo.txt insgesamt 12 drwxr-xr-x 3 root root 4096 2010-09-06 10:04 ./ drwxr-xr-x 33 administrator administrator 4096 2010-09-14 22:13 ../ drwx-- 3 root root 4096 2010-09-06 10:04 3/ This is the problem: First, /home/administrator/.openoffice.org is owned by root and not writable by anybody else (esp. not administrator). Second, /home/administrator/.openoffice.org/3 is owned by root and not even traversable by anybody else (esp. not administrator). Whatever you did to end up with such a setup, if I just knew, if I just knew... :( I suggest you sudo chown -R administator:administrator /home/administrator/.openoffice.org to clean up the mess. :) :-) Thank you very much for your efforts ! Best Regards ---rony P.S.: Just noticed today, that I may have not been subscribed to this list, so I explicitly subscirbed to it (sorry to the list moderator). - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Ubuntu desktop 10.4.1 de: Cannot start OOo, because
Hi Stephan, thank you very much for your feedback! The logfile (and a text-file giving information on the system) can be found at: http://wi.wu.ac.at/rgf/tmp/OOo/. Please do not invest too much time as I am confident that uninstalling Ubuntu's OOo and installing the genuine OOo will make OOo available with scripting on that particular machine (so it is more curiosity than necessity to figure out what is happening on that Ubuntu-10.04-desktop installation, which came without Java orginally). Regards, ---rony On 13.09.2010 17:47, Stephan Bergmann wrote: On 09/13/10 15:13, rony wrote: O.K., I uninstalled everything on this weekend that smelled like Java, however the behaviour of the Ubuntu-installed OOo did not change, i.e. OOo could not get started, the error message is just: Running soffice from the command line gives the following output on the commandline: javaldx failed! So, this happens while no genuine (from download.openoffice.org) OOo is installed, just the one that comes with Ubuntu? (Otherwise, it could be some unexpected interference between the two installations.) What might give a clue is to run strace -f -o logfile .../soffice (with ... replaced with the path to soffice) and make the resulting logfile (which can be huge) available. Strictly speaking, this is probably the wrong forum for this problem, as it appears to be specific to the Ubuntu-specific OOo, but I might nonetheless find time to have a quick glance at the output, to see if something obvious goes wrong. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Ubuntu desktop 10.4.1 de: Cannot start OOo, because
O.K., I uninstalled everything on this weekend that smelled like Java, however the behaviour of the Ubuntu-installed OOo did not change, i.e. OOo could not get started, the error message is just: Running soffice from the command line gives the following output on the commandline: javaldx failed! Did not uninstall the Ubuntu OOo (and reinstall the genuine one) for the time being, such that I would be able to test whatever people think may help clarify the problem. (OTOH, it may be the case that something went wrong installing the Java distributions and although uninstalling all Java may have left over some settings that are causing this phenomenon.) ---rony On 06.09.2010 20:36, rony wrote: On 06.09.2010 16:47, Stephan Bergmann wrote: On 09/06/10 12:39, rony wrote: On 06.09.2010 11:55, Stephan Bergmann wrote: On 09/06/10 11:37, Rony G. Flatscher wrote: After a fresh install of a German Ubuntu-desktop 10.4.1 and starting any OOo module a popup error comes along informing one that OOo cannot determine the user-interface language and then aborts. So that would be the OOo included in the Ubuntu distro, right? Yes. Was there any OOo user data left from a previous OOo (probably some hidden directory starting with .o in the home directory)? No, it was a fresh install on a freshly formatted partition. Which OOo version is this, by the way? 2.3.0 AFAIR. headless openjdk got installed (there was no Java installed at all), Before trying out OOo the first time on that new installation the OOo without Java should work fine (minus the parts using Java, of course), so you might want to check whether OOo starts if you remove Java again. Will try to do that, the machine is not in my realm anymore, but I should get access on the weekend the latest. ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Passive UNO Component Registration
Stephan: On 08.09.2010 14:34, Stephan Bergmann wrote: As has already leaked during OOoCon :) I am currently working on a new, passive way to register UNO components (removing the need for component_writeInfo, regcomp, and friends). See http://wiki.services.openoffice.org/wiki/Passive_Component_Registration for the details. (While, strictly speaking, this is UNO specific and should thus go to d...@udk.openoffice.org, I consider its consequences for all of OOo important enough to warrant this wider distribution.) that looks very interesting! Approximately when would you think this infrastructure will be available (maybe the earliest estimation) ? ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Ubuntu desktop 10.4.1 de: Cannot start OOo, because the UI language cannot be determined !
On 06.09.2010 16:47, Stephan Bergmann wrote: On 09/06/10 12:39, rony wrote: On 06.09.2010 11:55, Stephan Bergmann wrote: On 09/06/10 11:37, Rony G. Flatscher wrote: After a fresh install of a German Ubuntu-desktop 10.4.1 and starting any OOo module a popup error comes along informing one that OOo cannot determine the user-interface language and then aborts. So that would be the OOo included in the Ubuntu distro, right? Yes. Was there any OOo user data left from a previous OOo (probably some hidden directory starting with .o in the home directory)? No, it was a fresh install on a freshly formatted partition. Which OOo version is this, by the way? 2.3.0 AFAIR. headless openjdk got installed (there was no Java installed at all), Before trying out OOo the first time on that new installation the OOo without Java should work fine (minus the parts using Java, of course), so you might want to check whether OOo starts if you remove Java again. Will try to do that, the machine is not in my realm anymore, but I should get access on the weekend the latest. ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Ubuntu desktop 10.4.1 de: Cannot start OOo, because the UI language cannot be determined !
Hi there, not having found an appropriate e-mail list to report/ask about this problem, but hoping that some soul kind can give hints/advice. Please advise what mailing list would be the appropriate one for questions like this. After a fresh install of a German Ubuntu-desktop 10.4.1 and starting any OOo module a popup error comes along informing one that OOo cannot determine the user-interface language and then aborts. Running soffice from the command line gives http://wi.wu.ac.at:8002/rgf/tmp/OOo/ErrorOOo-on-Ubuntu-10.4.1-desktop-German.png gives the following output on the commandline: [Java framework] Error in function createSettingsDocument (elements.cxx). javaldx failed! Before installing the community edition of OOo I just was wondering what the cause of such an unexpected behaviour could be (giving a bad impression on the casual user who may want to look into OOo and learns, that it does not work) and how to remedy it? TIA, ---rony
Re: [dev] Ubuntu desktop 10.4.1 de: Cannot start OOo, because the UI language cannot be determined !
On 06.09.2010 11:55, Stephan Bergmann wrote: On 09/06/10 11:37, Rony G. Flatscher wrote: After a fresh install of a German Ubuntu-desktop 10.4.1 and starting any OOo module a popup error comes along informing one that OOo cannot determine the user-interface language and then aborts. So that would be the OOo included in the Ubuntu distro, right? Yes. Looks completely broken, esp. strange on a fresh install. Yes. Before trying out OOo the first time on that new installation the headless openjdk got installed (there was no Java installed at all), then after learning that headless meant headless (ie. no awt support) I downloaded the version that contained it, if that makes a difference. (That UI language cannot be determined message is somewhat of a red herring, it typically means that the OOo installation is so screwed up that starting it fails really early, trying to access the first UNO component, which happens to be configmgr.) Ah, I see, thank you very much for your explanations! Regards, ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Genuine OOo in distributions ? (Re: [dev] OOo installation packages for Linux, a few (easy) questions
Retrying... On 24.08.2010 11:54, rony wrote: Hi René, On 24.08.2010 10:38, Rene Engelhard wrote: rony, OK please try $ cd /usr/lib/ure/share/java $ ln -f ../../../../share/java/openoffice/jurt.jar jurt.jar Yup, that makes it work ! ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Genuine OOo in distributions ? (Re: [dev] OOo installation packages for Linux, a few (easy) questions
Hi René, On 24.08.2010 10:38, Rene Engelhard wrote: rony, OK please try $ cd /usr/lib/ure/share/java $ ln -f ../../../../share/java/openoffice/jurt.jar jurt.jar Yup, that makes it work ! ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Genuine OOo in distributions ? (Re: [dev] OOo installation packages for Linux, a few (easy) questions
Hi René, hi Michael, just managed to re-install the Ubuntu version of OOo. Out of the box the reported error occurs. Then, following Michael's advice and adding /usr/lib/ure/lib/ to CLASSPATH resolved the problem and OOo can be addressed via Java from the commandline ! So there is at least a problem in the Ubuntu distribution with the setup somewhere. Regards, ---rony On 23.08.2010 11:42, Michael Stahl wrote: On 21/08/2010 23:57, rony wrote: Hi René, sorry that it took a while to get back, but I got totally carried away changing/enhancing the installation scripts and had to get everything into sync again, before coming back to check out and analyze the problem with the Ubuntu distribution. Here's to what boils it down: * Using latest 64-bit Ubuntu, having everything updated to today, * Running an ooRexx script which uses the OOo/UNO Java bridge to interact with OOo, yielding the following error: 40 *-* xContext = UNO.connect() -- connect to server and retrieve the XContext object REX0040E: Error 40 running /usr/bin/UNO.CLS line 1804: Incorrect call to routine REX0634E: Error 40.900: BSF4ooRexx/routine/BSF(), error 3: Java exception occurred: [org.apache.bsf.BSFException: /// Java-exception (RexxAndJava) occurred: [java.lang.reflect.InvocationTargetException], g*etCause(): [java.lang.UnsatisfiedLinkError: com.sun.star.lib.connections.pipe.PipeConnection.createJNI(Ljava/lang/String;)I*] i think i remember this error... it is caused by not finding some URE dynamic libraries, like libjpipe.so. the Java UNO bridge apparently uses native code via JNI for some things. \\\?BSF4ooRexx subfunction invoke: object 'java.lang.cl...@593d93f4' - method [FINDINTERFACEWITHMEMBER], method not found or error (exception) executing method!] Uninstalling the Ubuntu OOo and instead installing the genuine OOo, downloaed from http://OpenOffice.org/download, installing it and running the very same program works without an error! In the case it matters, here is the CLASSPATH setting for the Ubuntu OOo: /opt/BSF4ooRexx/bsf-v400-20090910.jar:/opt/BSF4ooRexx/bsf-rexx-engine.jar:.::/usr/lib/openoffice/program/../basis-link/ure-link/share/java/ridl.jar:/usr/lib/openoffice/program/../basis-link/ure-link/share/java/jurt.jar:/usr/lib/openoffice/program/../basis-link/ure-link/share/java/juh.jar:/usr/lib/openoffice/program/../basis-link/program/classes/unoil.jar:/usr/lib/openoffice/progra on a Ubuntu box here the libraries seems to be in /usr/lib/ure/lib/libjpipe.so so try adding /usr/lib/ure/lib/ to CLASSPATH, see if that helps. The genuine OOo will have practically the same setting, except that its directory would be pointed to: /opt/openoffice.org3/program/../basis-link/ure-link/share/java/*. HTH, ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Instance of OOo running after unopkg ?
Hi there, for installing an extension (under Ubuntu in this particular case) in an installation script the command-line tool unopkg is used. When starting OOo thereafter a warning comes up that an instance of OOo would be running, and if one would like to proceed. Is this an expected behaviour? Is there a command-line utility which one could use to make sure that after unopkg OOo gets reliably shutdown? Or with other words: how could one make sure in an un/installation script, that OOo has completely shut down after unopkg, before proceeding ? ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] XDesktop.terminate() Re: [dev] Instance of OOo running after unopkg ?
Hi there, ... cut ... Just a quick question (which would save me a little bit of research. which currently would be quite helpful): how can I make sure, having a xContext (from com.sun.star.comp.helper.Bootstrap.bootstrap()) to shutdown OOo gracefully at the end? (Presumably not closing OOo explicitly leavees an instance open.) sorry for the noise, just found what I need: XDesktop.terminate(). ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Instance of OOo running after unopkg ?
Hi René, On 23.08.2010 16:05, Rene Engelhard wrote: On Mon, Aug 23, 2010 at 04:01:45PM +0200, Rony G. Flatscher wrote: for installing an extension (under Ubuntu in this particular case) in an installation script the command-line tool unopkg is used. When starting OOo thereafter a warning comes up that an instance of OOo would be running, and if one would like to proceed. Is this an expected behaviour? Nope. I don't see that in all the packages here which use unopkg in their preinst/postinst/prerm. Thank you very much for this hint! Going back because of it, I just noticed that unopkg is not the culprit, but a script that runs afterwards, so it is my own fault probably. Sorry for the wrong alarm. Just a quick question (which would save me a little bit of research which currently would be quite helpful): how can I make sure, having a xContext (from com.sun.star.comp.helper.Bootstrap.bootstrap()) to shutdown OOo gracefully at the end? (Presumably not closing OOo explicitly leavees an instance open.) ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Genuine OOo in distributions ? (Re: [dev] OOo installation packages for Linux, a few (easy) questions
On 23.08.2010 14:09, Rene Engelhard wrote: On Mon, Aug 23, 2010 at 11:42:22AM +0200, Michael Stahl wrote: i think i remember this error... it is caused by not finding some URE dynamic libraries, like libjpipe.so. the Java UNO bridge apparently uses native code via JNI for some things. Then that is a bug in the bridge or the extension itself IMHO ... The extension just employs the Bootstrap class if invoked outside of OOo. n a Ubuntu box here the libraries seems to be in /usr/lib/ure/lib/libjpipe.so so try adding /usr/lib/ure/lib/ to CLASSPATH, see if that helps. ... because ure-link is exactly what points to that /usr/lib/ure thing. Anything which assumes that the ure is inside the OOo dir is wrong; the only valid assumption is that *ure-link* is. That's how the three-layewr OOo interface was defined. What would be the easiest way to re-install the Ubuntu-OOo after deinstalling the genuine OOo? (Or do I have to go through Synaptic manager and check all sort of modules (with the risk that I am overlooking an important one, given that the OOo related modules seem to be quite dispersed.) ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Genuine OOo in distributions ? (Re: [dev] OOo installation packages for Linux, a few (easy) questions
Hi René, sorry that it took a while to get back, but I got totally carried away changing/enhancing the installation scripts and had to get everything into sync again, before coming back to check out and analyze the problem with the Ubuntu distribution. Here's to what boils it down: * Using latest 64-bit Ubuntu, having everything updated to today, * Running an ooRexx script which uses the OOo/UNO Java bridge to interact with OOo, yielding the following error: 40 *-* xContext = UNO.connect() -- connect to server and retrieve the XContext object REX0040E: Error 40 running /usr/bin/UNO.CLS line 1804: Incorrect call to routine REX0634E: Error 40.900: BSF4ooRexx/routine/BSF(), error 3: Java exception occurred: [org.apache.bsf.BSFException: /// Java-exception (RexxAndJava) occurred: [java.lang.reflect.InvocationTargetException], g*etCause(): [java.lang.UnsatisfiedLinkError: com.sun.star.lib.connections.pipe.PipeConnection.createJNI(Ljava/lang/String;)I*] \\\?BSF4ooRexx subfunction invoke: object 'java.lang.cl...@593d93f4' - method [FINDINTERFACEWITHMEMBER], method not found or error (exception) executing method!] Uninstalling the Ubuntu OOo and instead installing the genuine OOo, downloaed from http://OpenOffice.org/download, installing it and running the very same program works without an error! In the case it matters, here is the CLASSPATH setting for the Ubuntu OOo: /opt/BSF4ooRexx/bsf-v400-20090910.jar:/opt/BSF4ooRexx/bsf-rexx-engine.jar:.::/usr/lib/openoffice/program/../basis-link/ure-link/share/java/ridl.jar:/usr/lib/openoffice/program/../basis-link/ure-link/share/java/jurt.jar:/usr/lib/openoffice/program/../basis-link/ure-link/share/java/juh.jar:/usr/lib/openoffice/program/../basis-link/program/classes/unoil.jar:/usr/lib/openoffice/progra The genuine OOo will have practically the same setting, except that its directory would be pointed to: /opt/openoffice.org3/program/../basis-link/ure-link/share/java/*. HTH, ---rony On 17.08.2010 21:32, rony wrote: Hi René, On 17.08.2010 21:05, Rene Engelhard wrote: On Mon, Aug 16, 2010 at 06:49:24PM +0200, rony wrote: (Due to a package that excercises the Java-UNO-bridge I have stumbled over Ubuntu's distro which seems to be broken in that area and read Where exactly? (Ubuntu borrows my packages and breaks them at times, but what you experience could also be bug in Debian, so...) I noticed that in the Java bindings when trying to install the ooRexx scripting framework (which extends from OOo's Java scirpting framework and which macros get dispatched via this Java infrastructure). Have one 64-bit Ubuntu untampered which I will take a closer look tomorrow evening, trying to come up with more (hopefully useful) pointers. about other distributions that at least used to cripple OOo by removing some if not all of the genuine Java support). used to is right, I think nowadays all ship it compiled with OpenJDK at least on mainstream architectures. (Or use Sun JDK, which truly free distros of course cannot use). Grüße/Regards, ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] OOo installation packages for Linux, a few (easy) questions
Hi Sigrid, thank you very much for your interesting and helpful answers! * the package (3.2.1) just has an update script, but not an install script which makes it very cumbersome to install the genuine OOo from all the individual packages in the DEB subdirectory (after having removed the Ubuntu version of OOo beforehand): where could one find/locate the appropriate install script? Isn't it just enough to go into the directory and use the command dpkg -i *.deb (or something similar, I've never had a Debian-based system). With rpm or urpmi you can just do this, and the installer figures out, what to install first. That easy ? ;) Again, thank you very much (and also Konstantin!). As I have never used dpkg directly I was not aware of that functionality at all. * does the genuine OOo install into /opt on Fedora or SuSE as well? I can tell you, that on Mandriva OOo installs itself into /opt, so I would expect a similar behaviour on Fedora and SuSE as well, since the rpm-packages are all the same. ;) Good to know!Maybe a last question: which Linux distributions are known to be 100% Regards, ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Genuine OOo in distributions ? (Re: [dev] OOo installation packages for Linux, a few (easy) questions
Björn, On 16.08.2010 16:56, Björn Michaelsen wrote: Am Mon, 16 Aug 2010 16:12:50 +0200 schrieb Rony G. Flatscher rony.flatsc...@wu-wien.ac.at: Maybe a last question: which Linux distributions are known to be 100% compatible in their Java interfaces to OOo with the genuine OOo ? At least openoffice-bin on gentoo as it _is_ the genuine OOo build by Hamburg RelEng. Great, thank you very much for this information! Does anyone of any other distributions by any chance? (Due to a package that excercises the Java-UNO-bridge I have stumbled over Ubuntu's distro which seems to be broken in that area and read about other distributions that at least used to cripple OOo by removing some if not all of the genuine Java support). Regards, ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Genuine OOo in distributions ? (Re: [dev] OOo installation packages for Linux, a few (easy) questions
Hi René, On 17.08.2010 21:05, Rene Engelhard wrote: On Mon, Aug 16, 2010 at 06:49:24PM +0200, rony wrote: (Due to a package that excercises the Java-UNO-bridge I have stumbled over Ubuntu's distro which seems to be broken in that area and read Where exactly? (Ubuntu borrows my packages and breaks them at times, but what you experience could also be bug in Debian, so...) I noticed that in the Java bindings when trying to install the ooRexx scripting framework (which extends from OOo's Java scirpting framework and which macros get dispatched via this Java infrastructure). Have one 64-bit Ubuntu untampered which I will take a closer look tomorrow evening, trying to come up with more (hopefully useful) pointers. about other distributions that at least used to cripple OOo by removing some if not all of the genuine Java support). used to is right, I think nowadays all ship it compiled with OpenJDK at least on mainstream architectures. (Or use Sun JDK, which truly free distros of course cannot use). Grüße/Regards, ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] OOo installation packages for Linux, a few (easy) questions
Hi there, not sure whether this is the correct e-mail list. If not please advise, which one would be the appropriate one. An observation, two questions ad the OOo installateion packages on http://download.openoffice.org/index.html; when entered from a German, 32-bit Ubuntu system: * the package (3.2.1) just has an update script, but not an install script which makes it very cumbersome to install the genuine OOo from all the individual packages in the DEB subdirectory (after having removed the Ubuntu version of OOo beforehand): where could one find/locate the appropriate install script? * does the genuine OOo install into /opt on Fedora or SuSE as well? Maybe a last question: which Linux distributions are known to be 100% compatible in their Java interfaces to OOo with the genuine OOo ? TIA, ---rony
[dev] German extension-description text with umlauts referred to in description.xml, howto ?
It seems that the extension-description element in a description.xml file can refer to multiple files that each are authored in a different language, e.g.: extension-description src xlink:href=information/description_de.txt lang=de/ src xlink:href=information/description_en.txt lang=en/ /extension-description However, testing the German description file shows the German umlauts with the wrong glyphs in the extension manager, which may indicate that the codepage used by OOo to display the text is not matching the codepage the text got created with. What codepage should a German extension description file be authored, in order for the package manager to dipslay the German umlauts correctly? (Alternatively, is there a place where one could explicitly determine which codepage got used to create that text? If so, where and how could that be done?) ---rony
Re: [dev] Question ad OOo update feature ...
Hi Joachim, thank you *very much* for the following link: You can find information about the update information here: http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Extensions/Description_of_the_Update_Information It really helped me set up the relevant update.xml file such that it works (and it works great and as intended!). Regards, ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Announcement: IDL-XML-Converter - A Package for Transforming IDL into XML available ...
Hi there, today a student, Lukas Schreier, turned in his final version of a seminar paper about IDL-XML-Converter - A Package for Transforming IDL into XML. Here's the author's abstract: Author's abstract: The IDL-XML-Converter-Package is used to convert IDL to XML files. Those XML files can then be used to write an appropriate OpenOffice-Registry. The package includes the following functions: * Converting IDL-files into XML files, * Converting XML files into an OpenOffice-Registry format, * Converting OpenOffice-Registries into XML files, * Merging two OpenOffice-Registries. The content of the package consists of six Java programs, which are published under the LGPLv3- license. |idl2xml.jar| This program converts an existing OpenOffice.org IDL file into an XML file. |XMLReg.jar| Writes an XML file which contains OpenOffice IDL-types into an OpenOffice-Registry file. |RegXML.jar| Extracts a given OpenOffice-Registry key into an XML file. |RegMerge.jar| Merges two specified OpenOffice-Registries into one. The paper (in PDF), which documents the registry and the Java-based classes and the DTD that he developed for transforming IDL into XML, registry into XML, XML into registry, and merging registries can be fournd with its accompanying materials (source code, jars, examples) here: http://wi.wu-wien.ac.at/rgf/diplomarbeiten/index.htm#sem_201007a. ---rony
Re: [dev] Changed an extension from .jar to .oxt, now extension gets installed but cannot be used ?
Hi Oliver,
thank you *very* much for your hint and pointer!
Unfortunately, I have not found a means to get the class registered. Do
I have to explicitly name that class to register in the
META_INF/manifest.xml (and if so, how would that be done)? Currently
the META-INF/MANIFEST.MF contains the appropriate entry
(RegistrationClassName:
com.sun.star.script.framework.provider.oorexx.ScriptProviderForooRexx).
On 25.07.2010 19:19, Oliver Brinzing wrote:
Is there something I must also denote in the description.xml file to
you need a META-INF\manifest.xml where you list all your files, for example:
... cut (thank you very much for that very helpful snippet!) ...
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Extensions/File_Format
Thank you very much for this link as well!
Here is my current, timid manifest.xml, which does not cause the
RegistrationClassName to be followed:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE manifest:manifest PUBLIC -//OpenOffice.org//DTD Manifest
1.0//EN Manifest.dtd
manifest:manifest xmlns:manifest=http://openoffice.org/2001/manifest;
manifest:file-entry manifest:full-path=%origin%
manifest:media-type=application/vnd.sun.star.uno-component;type=Java /
/manifest:manifest
Did leave out the manifest:full-path attribute to no avail, using .
instead of %origin% or using ScriptProviderForooRexx.oxt would not
make a change. Supplying the name of the jar-file itself did not help
either.
Running unopkg list --shared copyin and pasting the information about
that oxt gives:
Identifier: org.oorexx.uno-via-BSF4ooRexx
Version: 4.04
URL:
vnd.sun.star.expand:$UNO_SHARED_PACKAGES_CACHE/uno_packages/F.tmp_/ScriptProviderForooRexx.oxt
is registered: n/a
Media-Type: application/vnd.sun.star.package-bundle
Description: This extension to OpenOffice.org (OOo) adds the easy to
learn,
yet powerful scripting language Open Object Rexx (ooRexx).
As a result it becomes possible to add and deploy macros programmed
in ooRexx from within OOo.
ooRexx:http://www.ooRexx.org
BSF4ooRexx: http://wi.wu.ac.at/rgf/rexx/bsf4oorexx/current/
bundled Packages: {
none
}
Greatful for any further hints/suggestions!
---rony
Re: [dev] Changed an extension from .jar to .oxt, now extension gets installed but cannot be used ?
Hi Stephan, On 26.07.2010 09:20, Stephan Bergmann wrote: To avoid a misunderstanding: :) There was no misunderstanding at all on my side, but plain ignorance and missing experience/knowledge on my side, never having created an oxt-extension! (To my defense, I tried to research the developer guide and various search engines, but have not found the clues that would have helped me master this particular challenge.) You cannot rename ScriptProviderForooRex.jar to ScriptProviderForooRex.oxt and include a description.xml and META-INF/manifest.xml in that zip. Instead, you need to create a new zip ScriptProviderForooRex.oxt that includes ScriptProviderForooRex.jar, description.xml, and META-INF/manifest.xml. Then, a manifest:full-path=ScriptProviderForooRex.jar should work. Thank you *very* much for this vital information, which may have been so obvious for you and everyone else who has created Java based extensions, but was new for me! Just applied it and it now works like a charm! Again, kudos to you and Oliver! ---rony P.S.: Now, in hindsight (after your explanations) this makes perfect sense! - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Changed an extension from .jar to .oxt, now extension gets installed but cannot be used ?
Hi there, currently (for many years) I have been deploying a scripting extension using a .jar file, named ScriptProviderForooRexx.jar (adding the ooRexx language to OOo, such that ooRexx scripts can be dispatched via OOo as well). Now, this weekend I wanted to change the filetype to .oxt (ScriptProviderForooRexx.oxt) and adding a description.xml file with a few bells and whistles (icon, description, version number). At first everything seemed to be working o.k., the extension manager was able to install and remove the extension, displaying all what description.xml contained. However, the scripting engine does not get registered, it seems, although nothing else got changed (just added description.xml and two aubdirectories, images and information, to contain files that are referred to by description.xml). With other words, there is still a META-INF/MANIFEST.MF (unedited as of yet), containing a RegistrationClassName: Manifest-Version: 1.0 RegistrationClassName: com.sun.star.script.framework.provider.oorexx.S criptProviderForooRexx It seems that the extension manager is either not handling this (or not expecting an extension to the OOo scripting framework), at least not in the way I had expected it to. The description.xml file contains the following elements: description (root element) version identifier dependencies publisher release-notes display-name icon extension-description Is there something I must also denote in the description.xml file to cause the extension to be identified and registered as an extension to the OOo scripting framerwork, or am I missing something obvious ? [P.S.: Just renaming the extension back to '.jar' makes everything work again, but I loose the description.xml stuff, which is a little bit unfortunate.] TIA, ---rony
Re: [dev] Lifetime of Java objects representing UNO_ENUM values ?
Hi Stephan, On 16.07.2010 08:48, Stephan Bergmann wrote: On 07/15/10 22:10, Rony G. Flatscher wrote: today I stumbled over the following interesting (read: time-consuming) problem: while caching Java objects representing individual UNO_ENUM values, all of a sudden om.sun.star.lang.DisposedException started to be thrown. Here is one such received exception message: ... getCause(): [com.sun.star.lang.DisposedException: java_remote_bridge com.sun.star.lib.uno.bridges.java_remote.java_remote_bri...@105b99f is disposed] That DisposedException had more than likely a different reason. Java objects representing UNO enumeration type values are completely local -- none of their methods initiate any URP communication. This is the use case using the Java bridge, where invocations of UNO APIs via Java are carried out using Java reflection (this allows me to basically address UNO typelessly from the perspective of Rexx users): * get all the enum values of com.sun.star.style.ParagraphAdjust and cache them for later use, e.g. the value for RIGHT is assigned to a local variable named right, * then, later, an XParagraphCursor is queried for its XPropertySet and then this is used to setPropertyValue(ParaAdjust, right). It is in this invocation where unexpectedly the above exception is thrown. Now, querying for the enum value RIGHT before using it in the setPropertyValue() works reliably. As I found a stable solution, this is more a report than a request for help, yet, it would be interesting to learn where and under what conditions such an exeption would be throwable. ---rony
Re: [dev] Lifetime of Java objects representing UNO_ENUM values ?
Hi Stephan, On 16.07.2010 14:51, Stephan Bergmann wrote: On 07/16/10 13:48, rony wrote: On 16.07.2010 08:48, Stephan Bergmann wrote: On 07/15/10 22:10, Rony G. Flatscher wrote: today I stumbled over the following interesting (read: time-consuming) problem: while caching Java objects representing individual UNO_ENUM values, all of a sudden om.sun.star.lang.DisposedException started to be thrown. Here is one such received exception message: ... getCause(): [com.sun.star.lang.DisposedException: java_remote_bridge com.sun.star.lib.uno.bridges.java_remote.java_remote_bri...@105b99f is disposed] That DisposedException had more than likely a different reason. Java objects representing UNO enumeration type values are completely local -- none of their methods initiate any URP communication. This is the use case using the Java bridge, where invocations of UNO APIs via Java are carried out using Java reflection (this allows me to basically address UNO typelessly from the perspective of Rexx users): * get all the enum values of com.sun.star.style.ParagraphAdjust and cache them for later use, e.g. the value for RIGHT is assigned to a local variable named right, * then, later, an XParagraphCursor is queried for its XPropertySet and then this is used to setPropertyValue(ParaAdjust, right). It is in this invocation where unexpectedly the above exception is thrown. Now, querying for the enum value RIGHT before using it in the setPropertyValue() works reliably. Can you present the exact failing code here? What type is the variable named right, and how exactly does the (reflective, IIUC) call to setPropertyValue look like? Yes, but you need to fasten your seat-belt! ;-) Reason being the following architecture: * ooRexx (C++) interacting with Java via an external function call package for ooRexx (C++) that communicates with Java via JNI (C++), * Java support classes which partly use the Apache Software Foundation's Bean Script Framework 2.x, * an ooRexx package named UNO.CLS that is tailored to ease interaction with UNO, taking advantage of ooRexx mechanisms (e.g. instead of the programmer issuing explicitly a Runtime.queryInterface(...) this is done in UNO.CLS, if the programmer merely sent the name of an interface as a message to the UNO Rexx object, etc.). Realizing the complexity of the architecture (which has evolved for the past four years with the specific OOo/UNO support package) I am always wary, when analyzing or reporting errors. In the concrete case the following code snippet had failed: ... cut ... /* make all of the UNO_ENUM values easily available to Rexx: */ paraEnum=.uno_enum~new(com.sun.star.style.ParagraphAdjust) /* for debugging: show all values */ say UNO_ENUM 'ParagraphAdjust': pp(paraEnum~makeString) /* get properties of XParagraphCursor */ xParagraphCursorProps=xTextCursor~XParagraphCursor~XPropertySet /* for debugging: show the definition, including all available properties */ say 'xParagraphCursorProps': ppd(xParagraphCursorProps~uno.getDefinition) /* right adjust paragraph */ xTextCursor~gotoEnd(.false) xText~insertControlCharacter(xTextCursor, ctlConstants~paragraph_Break, .false) xText~insertString(xTextCursor, This paragraph will be right-adjusted. ~copies(6), .true) *xParagraphCursorProps~setPropertyValue(ParaAdjust, paraEnum~right)* ^^^ failure with the reported exception ^^^ In the typeless (actually late binding) ooRexx (http://www.ooRexx.org) there is an explicit message operator (the tilde, ~) which means that the object left of the tilde will get the message sent to, that is given right of the tilde. If a message carries arguments, then these arguments can be enclosed in round parentheses. The statement paraEnum=.uno_enum~new(...) uses the ooRexx class UNO_ENUM defined in UNO.CLS to wrap an UNO_ENUM. The result is that one then merely needs to send the enum value's name as a message and will get the enum (Java) object returned. This is done in the last statement above, setting the ParaAdjust property. The ooRexx class UNO_ENUM would cache all enum (Java object) values and return them. In the process of analyzing the problem I also explicitly queried the enum (Java object) value right before the last statement above and it returned the same Java object, that has been cached. Except, in the latter case the exception was not thrown and the code worked. As a result I changed the implementation of the UNO_ENUM ooRexx class to not return a cached enum (Java object) value, but query that value at that point in time and return it. And the problem went away ... [I know, you might be inclined to think that the caching in UNO_ENUM does not work, but I can assure you that I double-checked on that. In a nutshell
[dev] Lifetime of Java objects representing UNO_ENUM values ?
Hi there, today I stumbled over the following interesting (read: time-consuming) problem: while caching Java objects representing individual UNO_ENUM values, all of a sudden om.sun.star.lang.DisposedException started to be thrown. Here is one such received exception message: ... getCause(): [com.sun.star.lang.DisposedException: java_remote_bridge com.sun.star.lib.uno.bridges.java_remote.java_remote_bri...@105b99f is disposed] Caching the Java class object and querying it for the field values in the same use-case (and timing) conditions worked. Question: is caching of Java objects representing individual UNO_ENUM values really unsafe, i.e. the UNO side may garbage collect them? (This seems to happen even if the Java class object representing the UNO_ENUM gets cached!) ---rony
[dev] Windows' unopkg.exe does not differentiate between stderr and stdout, where does stdout go to when piping ?
Hi there, experimenting with OOo 3.2's unopkg.exe (under WindowsXP, SP3) it seems, that the output from unopkg.exe is only directed at stdout, whereas under Linux error messages (like given package not installed and the like) are directed to stderr, and normal messages to stdout. Is this intentional or a bug? Furthermore, trying to pipe normal output to grep seems to not work, i.e. something like: unopkg list --shared | grep CACHE would not work on Windows, but would under Linux (i.e. display the lines containing the string CACHE). (Yes, I made sure that the string is output as a result of running unopkg list --shared. The grep I am using on Windows is: GNU grep 2.5.3.) Actually, the following does not work either under Windows: unopkg list --shared test.txt test.txt would be a 0-byte file. Any ideas? ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Question ad creating and deploying components, implemented in (dispatchable) scritpting languages ...
Hi there, if this is not the right list, please advise. [This e-mail is directed at d...@api.openoffice.org and dev@openoffice.org, and the Reply-To-field set to d...@openoffice.org.] After peeking around the documentation (mainly developer's guide) currently one is able to create componenents in C++ and Java (and also in Python). The question: how would one create and implement UNO components in scripting languages that can be deployed via the OOo (Java-based) scripting framework (e.g. JavaScript/Rhino, BeanShell, but also ooRexx or other BSF-scripting languages)? Some of the questions that may be needed to be addressed would be: * How can one dynamically add IDL kind of type information to the registry, such that the new types become reflectable? * How can one register a component dynamically ? * How can one supply a service manager object to be used for instantiating instances? * How can one take advantage of helper classes (XWeak, XComponent) ? Are there any links/hints to postings, definitions, sketches of such a functionality? Is there some experimental implementation available somewhere (or is it even available already)? Short of that, how is the Python support implemented? Is there a documentation about the architecture and the UNO APIs it uses? What are/were the problems there, are there any shortcomings? --- Maybe to rephrase this question differently: I would like to come up with a solution for OOo disptachable scripting languages, in which script programmers have no need for the OOo SDK, if they wish to create UNO components in their scripting language of choice. (The necessary complexity involved in creating UNO components, should be reduced to an absolute minimum, where this minimum should be to have no need for installing the OOo SDK.) TIA, ---rony
Re: [dev] UNO API exception specifications
Frank Schönheit - Sun Microsystems Germany wrote: Hi Stephan, The only problem I see is that classes implementing the respective interface need to be adjusted, too, which of course is error prone. If this adjustment is not made, implementations throwing the new exception might crash (at least on platforms where the compiler respects the throw specification on a method, and generates code to assure it). What about language bindings other than C++? Basic an Python ignore are not affected by changed exception specifications, as far as I understand. Java code would need to be recompiled, which would break until the code is adjusted (right?). However, this is probably something on the ¨to-be-accepted¨ list, if we allow for such a change in the UNO API (and this allowance was my premise for this discussion). What other language bindings are there? Out of the box BeanShell, JavaScript, and at least ooRexx in addition. All of these use the Java bridge, if I am not mistaken. The ooRexx binding would not have a problem at all with such a change, that I would regard of utmost importance. [Yes, I wholeheartedly agree, that the current situation is many times frustrating, especially for beginners in an area of OOo (even experts of one or two modules are beginners if turning to new modules). There is a lot of resources that is being wasted just to figure out what the original cause of an exception was, if possible at all.] ---rony
Re: [dev] UNO API exception specifications
Stephan Bergmann wrote:
On 03/11/09 15:12, rony wrote:
[Yes, I wholeheartedly agree, that the current situation is many
times frustrating, especially for beginners in an area of OOo (even
experts of one or two modules are beginners if turning to new
modules). There is a lot of resources that is being wasted just to
figure out what the original cause of an exception was, if possible
at all.]
*With figure out do you mean programatically (catching an exception
and trying to handle it, but having problems distinguishing the
different kinds of exceptions that got lumped together as runtime
exceptions due to missing exception raising specifications at UNO
methods)* o/r a programmer trying to understand a situation where an
exception was thrown/? In the latter case, I would not see how
Frank's proposal (change published UNO interfaces incompatibly by
changing their method's exception raising specifications) would help
here.
*The former: it is just frustrating to have a program bomb and get a
message like exception occurred. (Yielding the message: go, figure...)*
/The latter case you cite would eventually help too, if the new
exceptions carry meaningful/helpful information via the exception('s
type); this may do wonders helping the developer to quickly (or more
quickly) identify the nature/cause of problems and either fix it right
away or becoming able to jump-start the necessary research in a concrete
corner of the documentation or area of the code. /
---rony
P.S.: Sorry, used the openoffice-e-mail address which does not work
(posting held, moderator intervention needed).
Re: [dev] UNO API exception specifications
Stephan Bergmann wrote:
On 03/11/09 15:12, rony wrote:
[Yes, I wholeheartedly agree, that the current situation is many
times frustrating, especially for beginners in an area of OOo (even
experts of one or two modules are beginners if turning to new
modules). There is a lot of resources that is being wasted just to
figure out what the original cause of an exception was, if possible
at all.]
*With figure out do you mean programatically (catching an exception
and trying to handle it, but having problems distinguishing the
different kinds of exceptions that got lumped together as runtime
exceptions due to missing exception raising specifications at UNO
methods)* o/r a programmer trying to understand a situation where an
exception was thrown/? In the latter case, I would not see how
Frank's proposal (change published UNO interfaces incompatibly by
changing their method's exception raising specifications) would help
here.
*The former: it is just frustrating to have a program bomb and get a
message like exception occurred. (Yielding the message: go, figure...)*
/The latter case you cite would eventually help too, if the new
exceptions carry meaningful/helpful information via the exception('s
type); this may do wonders helping the developer to quickly (or more
quickly) identify the nature/cause of problems and either fix it right
away or becoming able to jump-start the necessary research in a concrete
corner of the documentation or area of the code. /
---rony
Re: [dev] DevGuide Wiki / discussion of SDK examples / source code links into a repository
Hmm, may be it is too late already, but I do not quite understand your idea. So let me try to express it in my words: (1) The DevGuide, in particular with respect to presenting only code snippets in Java, should remain as it is. +1 (2) Boxes with code snippets in the DevGuide should have a link to the one(!) main examples page. So, starting from a code snippet in the DevGuide I click one link to get to the main examples page. +1 (3) The main examples page contains a list of all examples available. On this page I can click on another link to get to another page that discusses the particular example in Java (or any other language) which contains the code snippet from (1), where I started. (One page for every example or even one page for every example _and_ every language?) From this page, I can again navigate to other pages, giving me particulars about the project files for NB or Eclipse or, ... On these pages I might also find links to download the project files for the particular example for the respective IDE. If this is what you mean, where do I find the code? My idea was to start from (1) and find a link to a page where I can read the code on-line. A very good example about what I have in mind is [1]. When I learn something like UNO I don't have to build and run every example. Very often it is enough to just read the code. So it would be great if I could read it by just clicking some links -- refer to [1] again. +1 It would be cumbersome, if I had to download the example and install the project in an IDE in order to just read the code. Even worse, what if I don't use NB, and don't want to use it? If the examples are available only as NB projects, chances are high, that I will not only get frustrated, but that I will loose interest. +1 ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Runtime issues, if OOo Basic invokes Java, which bootstraps its own connection to OOo ? (Hangs OOo hard, OOo Basic macro enclosed)
Hi there, not being sure which e-mail list would be appropriate, I send it to those two that may help the most, but setting the reply-to field to d...@api.openoffice.org to avoid spamming multiple lists. If this is not appropriate please advise. Following use-case: * OOo Basic subroutine using the dispatch interface to dispatch an ooRexx macro/script, supplying it arguments (an UNO object to be documented explicitly and for which a writer document will be created which will receive formatted text with underlying links to the OOo UNO documentation), * the bridge to ooRexx (itself written in C++) is realized via Java as a bridge, using the OOo Java based scripting interface for communication; all communication between OOo and ooRexx is carried out via the Java bridge from the perspective of OOo. The problem: * The ooRexx script is invoked, but at the moment where on its side the Java com.sun.star.comp.helper.Bootstrap.bootstrap() is executed, in order to get an independent xContext, which then is used to create a com.sun.star.frame.Desktop UNO object, which then is used to get the xComponentLoader to use its loadComponentFromUrl(...) to load an empty swriter document, then there OOo hangs hard (need a task manager to kill it). * Doing the same with Java (i.e. invoking the very same ooRexx script/macro from a Java OOo app) works! Can someone shed some light on interdependencies between OOo Basic and invoked non-OOo-Basic code via Java that bootstraps independently to OOo in order to get a xContext? TIA, ---rony P.S.: Here's the OOo Basic code-snippet to invoke the ooRexx script via dispatch: -- cut here - Sub TestDispatchCreateApiInfoWithRexx Dim oDispHelper, oProvider as object Dim macroUrl as string dim args0(0) as new com.sun.star.beans.PropertyValue oProvider=ThisComponent.CurrentController.Frame oDispHelper=createUnoService(com.sun.star.frame.DispatchHelper) macroUrl=vnd.sun.star.script:wu_tools.createApiInfo.rex?language=ooRexxlocation=user args0(0).Name=arg1 args0(0).Value=oDispHelper ' some UNO object/IDL string r=oDispHelper.executeDispatch(oProvider, macroUrl, , 0, args0()) msgbox r.Result, 0, result from dispatching createApiInfo.rex End Sub -- cut here -
[dev] Now with OOo Basic called from pure Java ... (Re: [dev] More infos, request for help/hints ... (Re: [api-dev] XDispatchHelper.executeDisptatch(...) - Boolean argument appended by OOo ?
, RgfFuncTest()
RgfFuncTest=str
end function
-- cut here --
[BTW, please note that there seems to be an error in this area, as from
outside of Basic one must denote application rather than the correct
user as the location.]
Compiling and running the Java program above will cause a message box to
popup (needs to be closed by the user, or just comment the
MsgBox-instruction), and at the end of the run will display the result's
value (the result of the Basic function):
-- cut here --
F:\test\ooo\studenten\diplarbeit\scholz\20090108java TestBasic
Connected to a running office ...
Returned from executing dispatch, Result=[(some Basic datatypes: 0=Empty,
2=Integer, 8=String, 9=Object, 11=Boolean)
isMissing(arg1)=False, value=someObject, datatype=9
isMissing(arg2)=False, value=True, datatype=11
isMissing(arg3)=True], State=[1]
Successful run.
-- cut here --
As you can see, the Basic function gets TWO arguments, instead of only
one. The last argument is of type Boolean and has a value of True.
Any comments/hints/explanations now that only genuine OOo
functionality is used? Does this qualify as a bug?
Regards,
---rony
Rony G. Flatscher (Apache) wrote:
Hi there,
not sure whether dev@openoffice.org would be the better list for
this question, hence cc:'ing it, but reply-to is set to point to
d...@api.openoffice.org. Please advise, if another e-mail-list would be
better.
rony wrote:
Hi there,
it seems that if using XDispatchHelper.executeDisptatch(...) from Java
the argument list (fifth argument being an array of type PropertyValue)
gets a Boolean entry appended (that is always set to true). Is that
truly the case? (If so, where would that be documented?)
Using OOo 3.0.0 (O300m9, build:9358) and the Java interface to OOo to
invoke executeDispatch(). Online documentation
http://api.openoffice.org/docs/common/ref/com/sun/star/frame/XDispatchHelper.html#executeDispatch,
looking up Parameter Arguments.
TIA,
---rony
Maybe this was not enough information, so:
* Using XDispatchHelpter.executeDispatch(...), allows one to supply
five arguments, the last argument being an array of PropertyValues,
* Using the OOo scripting framework, the method invoke(Object[]
aParams, short[][] aOutParamIndex, Object[][] aOutParams) of the
com.sun.star.script.framework.provider.XXX.ScriptProviderForXXX
class is invoked (where XXX stands for the scripting language
this class will serve).
o aParams will have always one argument more than supplied
by XDispatchHelpter.executeDispatch(...), and that
argument is of type Boolean (in my case always set to true.
Here's an example Java code that employs
XDispatchHelper.executeDispatch(...):
- cut here
// ---rgf, 2009-02-11, Java program to invoke createApiInfo.rex from Java
import com.sun.star.beans.PropertyValue;
import com.sun.star.frame.XComponentLoader;
import com.sun.star.frame.XDesktop;
import com.sun.star.frame.XDispatchHelper;
import com.sun.star.frame.XDispatchProvider;
import com.sun.star.lang.XMultiComponentFactory;
import com.sun.star.lang.XMultiServiceFactory;
import com.sun.star.uno.UnoRuntime;
import com.sun.star.uno.XComponentContext;
import com.sun.star.frame.DispatchResultEvent;
class TestCreateApiInfo {
public static void main (String args[]) {
// excerpted from HardFormatting.java from the OOo development
package
XDesktop xDesktop = null;
XMultiComponentFactory xMCF = null;
XMultiServiceFactory xMSF = null;
try {
XComponentContext xContext = null;
// bootstrap the UNO runtime environment
xContext = com.sun.star.comp.helper.Bootstrap.bootstrap();
// get the service manager
xMCF = xContext.getServiceManager();
xMSF = (XMultiServiceFactory)
UnoRuntime.queryInterface(XMultiServiceFactory.class, xMCF);
if (xMSF!=null)
{
System.out.println(Connected to a running office ...);
// get XDispatchProvider from XDesktop
Object oDesktop =
xMSF.createInstance(com.sun.star.frame.Desktop);
xDesktop = (XDesktop)
UnoRuntime.queryInterface(XDesktop.class, oDesktop);
XDispatchProvider xDispatchProvider=(XDispatchProvider)
UnoRuntime.queryInterface(XDispatchProvider.class,
xDesktop);
Object sDispatchHelper=
xMSF.createInstance(com.sun.star.frame.DispatchHelper);
XDispatchHelper xDispatchHelper=(XDispatchHelper)
UnoRuntime.queryInterface(XDispatchHelper.class,
sDispatchHelper);
// define arguments
PropertyValue propValue=new PropertyValue
[dev] file-types ? (Re: [dev] Filter List for OOo 3?
Hi Andreas, please have a look on http://wiki.services.openoffice.org/wiki/Framework/Article/Filter. There you can find now a new list for OOo 3.0 ... Further you will find a small Basic Script which you can use to generate your own list. Very nice, thank you very much! Note: The script generates a simple HTML page - no content directly use able as Wiki content. But feel free to change the script so it exports the list using the right format .-) Is there a way to also get the file-type patterns for each filter? ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] file-types ? (Re: [dev] Filter List for OOo 3?
Hi Andreas, yes - it's possible. Inside the script you will find a function generateTypeView (). It's commented out. But it shows you how you can retrieve type properties as e.g. file extensions. If you do the following [e.g. at line 383] ... elseif fprops(p).Name = Type then type_registration = fprops(p).Value ... use type_registration ( which is an internal type name) ... to retrieve it's property Extensions and print it out endif you should be able to extend your list view very easy. Thank you *very* much, indeed! Regards, ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Filter List for OOo 3?
Hi Albert, Albert Law wrote: Hi Andrew, No, that's not good enough. I want the full names of the file formats, specific version information if available, and common file extensions associated with the supported filters. Maybe, if you research the online docs, starting out with com.sun.star.document.FilterFactory, which Andrew's code uses, you could assess what information about filters is available at runtime and what not. A nice starting point may be the xref for the FilterFactory http://api.openoffice.org/docs/common/ref/com/sun/star/document/FilterFactory-xref.html, which has links to the developer guide where more information about filters is given. The link to the FilterFactory is there as well or directly via: http://api.openoffice.org/docs/common/ref/com/sun/star/document/FilterFactory.html. Then http://api.openoffice.org/docs/common/ref/com/sun/star/document/TypeDetection.html, http://api.openoffice.org/docs/common/ref/com/sun/star/document/ExtendedTypeDetection.html with http://api.openoffice.org/docs/common/ref/com/sun/star/document/MediaDescriptor.html may be relevant in this context (and the information you seek) as well. Of course, once you are done, please share your findings in a nutshell with us ! :) [Seriously. If I were able to give you the needed information in a nutshell, I would do so. Not having time to go after that, I hope that at least those links to the relevant OOo online documentation are helpful for your research and experiments, in order to solve your problem. Your findings could be valuable for other readers of this list, hence the request to report back your findings/advice.] ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] getTextFields() - where to get additional infos
Hi Marten, Yes, these are hints, but you do not get this information from the IDL reference and it seems to be impossible to get this information via reflection. I created now around 3000 classes from doing reflection of the whole system and can't get this information. The following is an interactive session (starting ooRexx in a command line window, loading the uno/OOo support by calling the module uno.cls and then querying the definition of the service com.sun.star.text.TextFields using the IDL name) on Windows XP: F:\test\ooorexxtry REXX-ooRexx_3.2.0(MT) 6.02 16 Jun 2008 rexxtry.rex lets you interactively try REXX statements. Each string is executed when you hit Enter. Enter 'call tell' for a description of the features. Go on - try a few...Enter 'exit' to end. call uno.cls ... rexxtry.rex on WindowsNT str=com.sun.star.text.TextFields ... rexxtry.rex on WindowsNT say ppd(uno.getDefinition(str)) UNO_SERVICE|com.sun.star.text.TextFields| com.sun.star.container.XEnumerationAccess|UNO_INTERFACE||com.sun.star.text.TextFields com.sun.star.util.XRefreshable|UNO_INTERFACE||com.sun.star.text.TextFields ... rexxtry.rex on WindowsNT So the XRefreshable interface gets listed, and very easily so... :) --- Behind the curtains the UNO reflection mechanism is used to get to the information. Wrote a Java wrapper for it, which encodes the results in form of a string, that can be easily parsed according to p.2. on http://wi.wu-wien.ac.at/rgf/rexx/bsf4rexx/current/refcardOOo.pdf, right-most column, section entitled Table “UNOIDL String Encodings”. If you can interface with Java behind the curtain from Smalltalk then please say so and I will direct you to where to get that Java wrapper class (it took me *quite* some efforts to create it, but it works on all platforms: Linux, Macs, and Windows), which may help you as well in your efforts. ---rony P.S.: Of course I am always interested in seeing the Smalltalk snippets from time to time to relate to another posting of yours...
Re: [dev] getTextFields() - where to get additional infos
Hi Marten, just guessing. Marten Feldtmann wrote: How can this code run: ((mxDocument as XTextFieldsSupplier).getTextFields() as XRefreshable).refresh(); getTextFields() (by interface XTextFieldsSupplier) delivers com.sun.star.container.XEnumerationAccess and this interface does not understand refresh. Where in the idl reference do I get the information, that getTextFields() actually delivers an instance of com.sun.star.text.TextFields ? I do not get this information via the idl reference, nor by reflection Going to http://api.openoffice.org/docs/common/ref/com/sun/star/util/XRefreshable.html and choosing Use in the top menu, you get to http://api.openoffice.org/docs/common/ref/com/sun/star/util/XRefreshable-xref.html, where you see a reference to http://api.openoffice.org/docs/common/ref/com/sun/star/sdbcx/Container.html. From http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Collections_and_Containers it seems that XEnumerationAccess is a subclass of XContainer and as such possesses the XRefreshableInterface, which you then would neet to query explicitly from the XEnumerationAcess object. HTH, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] [Fwd: New BSF4Rexx released ...]
Hi there, FYI the announcement to the Rexx Language Association (http://www.RexxLA.org) members, informing them of a new version of BSF4Rexx, which includes updated support for OOo scripting and OOo macros using the scripting language ooRexx (http://www.oorexx.org/download.html). ooRexx itself is written in C++, the BSF4Rexx package enables ooRexx to camouflage Java as ooRexx (bridging ooRexx and Java in both directions). The ooRexx interaction with OOo uses the OOo Java bridge, hence the packaging of the OOo support with BSF4Rexx. ---rony Original Message Subject:New BSF4Rexx released ... Date: Fri, 19 Sep 2008 18:25:16 +0200 From: Rony G. Flatscher [EMAIL PROTECTED] To: RexxLA Members mailing list [EMAIL PROTECTED] Hi there, There is a new distribution of BSF4Rexx available from the official site, since today: http://wi.wu-wien.ac.at/rgf/rexx/bsf4rexx/current/. Please de-install your current BSF4Rexx before installing the new one (by running the previously created uninstallOOo and uninstallBSF scripts). To install: just download http://wi.wu-wien.ac.at/rgf/rexx/bsf4rexx/current/BSF4Rexx_install.zip, unzip the archive to a directory of your choice and follow the readme instructions for quickly installing BSF4Rexx. Some notable changes compared to previous versions: * If taking advantage of BSF.CLS each string value returned from the Java side will have either the string O or S prepended, which will get stripped automatically by all routines and classes of BSF.CLS. However, if you mix oo- and classic-Rexx style of interacting with Java (i.e. using the external Rexx function BSF() directly), then you need to get rid of the first three bytes that you receive from the Java side. The prepending is controlled by the new BSF() subfunction named bsfPrefixReturnValue which takes either .true or .false (cf. reference card). * the fully qualified path to the BSF4Rexx script is now supplied, if available, such that PARSE SOURCE can be used, * if adding an event handler to a Java class and supplying a wrong event name, then the error message will list all event set and their events to help the programmer correct the mistake (can be quite tedious to figure that one out), * when using BSF.CLS, then any error messages that have occurred on the Java side will be made available with the local environment symbol .BSF_ERROR_MESSAGE, no matter whether displaying those error messages are suppressed or not (cf. external BSF-function named BsfShowErrorMessage() on the reference card), * added entries file.separator, line.separator, and path.separator to the .BSF4Rexx directory, values retrieved from Java's System class which makes sure that the values are supplied according to the platform BSF4Rexx is running on * added new external Rexx function BsfDetach() to make the multithreading support for BSF4Rexx complete. Some notable changes to the OpenOffice (OOo) support (supplied via UNO.CLS) compared to previous versions: * added public routine uno.getScriptMetaData(), which allows to retrieve the OpenOffice metadata script object, if a Rexx script got invoked as a macro by OOo, cf. reference card for its arguments, * supplies script path, such that PARSE SOURCE can be used to retrieve the script's location, * added convenience routine uno.createProperty(name[,value]) to ease creation of property value objects, * template.rex: template code for new macros via the OOo UI now contains commented code to demonstrate how to address all kind of document types and how to react upon errors supplying the error messages in popups, * gives additional and very detailed error information aimed at helping the programmer to quickly realize the error and possible resolutions, * added public convenience routines methods uno.getInterfaceName(), uno.supportsService(name), uno.supportsInterface(name), * added supporting code for interacting with property values through the XPropertySet interface: property names now do not have to match the case, property values do not have to be explicitly boxed. Regards, ---rony
Re: [dev] Howto get the actual interface type of an UNO service object (via Java) ?
Hi Stephan, while poking around a little bit I was wondering, how one could get at the Type[...] information via Java that the Java proxy object reveals, if asking it to render to a string. E.g. in the following (interactive) session Java is used as the bridge for the scripting language ooRexx; first a Desktop service object is created and assigned to a variable a, then its com.sun.star.frame.XDesktop interface is assigned to variabel b and from it the com.sun.star.beans.XPropertySet interface is assigned to variable c. Sending the toString message to all three proxy objects displays them allowing to distinguish which interface type they represent. In the example session below (please watch out for line-wraps) that interface type is the last comma separated token in the form of Type[...interface_name...]. Now the question: how can one get at exactly that piece of information via Java at runtime? You can't, easily. (Maybe you can via reflection). As of DEV300m31, every Java proxy object must implement interface com.sun.star.lib.uno.Proxy (see jurt/com/sun/star/lib/uno/Proxy.java:1.4), and the two cases that do are defined in jurt/com/sun/star/lib/uno/bridges/java_remote/ProxyFactory.java:1.8 (for the remote URP bridge), storing the relevant data as private final Type type;, and in bridges/source/jni_uno/java/com/sun/star/bridges/jni_uno/JNI_proxy.java (for the in-process JNI bridge), storing the relevant data as protected Type m_type;. Thank you very much for these interesting pointers! Just another question: how about if I were to run the toString() method against a service object proxy and parse the type information. This way it's the proxy's toString()-method problem to figure out and supply the interface type. (Performance in the context of the thought for use-cases is not an issue at all, given those warped PCs people have come to use today.) Besides, that a proxy handles only a single interface (plus parent interfaces) of a UNO object is, of course, an implementation detail that can always change. Sure. Actually, what I am after is to determine at runtime whether the service object in hand got a queryInterface for a specific interface carried out already or not. Currently, it would be important to find out whether the com.sun.star.beans.XPropertySet interface was queried already (i.e. whether its methods would be available already, or whether one needs to query that interface). However, this may be interesting in other contexts, where a service object is returned and it may be interesting to know which interfaces got queried for already. ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Howto get the actual interface type of an UNO service object (via Java) ?
Hi there, while poking around a little bit I was wondering, how one could get at the Type[...] information via Java that the Java proxy object reveals, if asking it to render to a string. E.g. in the following (interactive) session Java is used as the bridge for the scripting language ooRexx; first a Desktop service object is created and assigned to a variable a, then its com.sun.star.frame.XDesktop interface is assigned to variabel b and from it the com.sun.star.beans.XPropertySet interface is assigned to variable c. Sending the toString message to all three proxy objects displays them allowing to distinguish which interface type they represent. In the example session below (please watch out for line-wraps) that interface type is the last comma separated token in the form of Type[...interface_name...]. Now the question: how can one get at exactly that piece of information via Java at runtime? E:\rony\dev\bsf\src\binrexxtry REXX-ooRexx_3.2.0(MT) 6.02 16 Jun 2008 rexxtry.rex lets you interactively try REXX statements. Each string is executed when you hit Enter. Enter 'call tell' for a description of the features. Go on - try a few...Enter 'exit' to end. call uno.cls ... rexxtry.rex on WindowsNT a=uno.createDesktop() /* creates and returns a desktop service object */ ... rexxtry.rex on WindowsNT b=a~XDesktop /* queries the com.sun.star.frame.XDestkop interface */ ... rexxtry.rex on WindowsNT c=b~XPropertySet /* queries the com.sun.star.beans.XPropertySet interface */ ... rexxtry.rex on WindowsNT say a~toString /* ask the proxy for its string representation */ [Proxy:9938272,4c801ac;msci[0];71a4c62fd6a4ea18dca702d3c4a726d,Type[com.sun.star.uno.XInterface]] ... rexxtry.rex on WindowsNT say b~toString /* ask the proxy for its string representation */ [Proxy:32134769,4c801ac;msci[0];71a4c62fd6a4ea18dca702d3c4a726d,Type[com.sun.star.frame.XDesktop]] ... rexxtry.rex on WindowsNT say c~toString /* ask the proxy for its string representation */ [Proxy:30495813,4c801ac;msci[0];71a4c62fd6a4ea18dca702d3c4a726d,Type[com.sun.star.beans.XPropertySet]] ... rexxtry.rex on WindowsNT say a~uno.getTypeName b~uno.getTypeName c~uno.getTypeName /* get the IDL type name via reflection */ UNO_SERVICE UNO_SERVICE UNO_SERVICE ... rexxtry.rex on WindowsNT say uno.areSame(a,b) uno.areSame(b,c) uno.areSame(a,c) /* test whether all three are the same object */ 1 1 1 ... rexxtry.rex on WindowsNT TIA for any pointers/hints, ---rony
Re: [dev] Java 1.5 now minimal requirement ? (Re: [dev] RFC: java 1.5
Stephan Bergmann wrote: Kay Ramme - Sun Germany - Hamburg wrote: Hi Rony, I did start the discussions regarding Java version, OpenJDK, baseline etc. on [EMAIL PROTECTED] Sorry for not announcing it here. Reason for [EMAIL PROTECTED] is, that all stakeholders from the last agreement originally were on that alias. Still, I would consider it an error if current OOo versions built for widespread distribution (e.g., Sun Hamburg built DEV300 m23) are built in a way that they do not work with at least Java 1.3.1 at runtime. This could be achieved by compiling with the -source and -target switches in effect which allow for creating the class files such, that they can be loaded in earlier releases (like in Java 1.3). ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Java 1.5 now minimal requirement ? (Re: [dev] RFC: java 1.5
Hi Kay, I did start the discussions regarding Java version, OpenJDK, baseline etc. on [EMAIL PROTECTED] Sorry for not announcing it here. Reason for [EMAIL PROTECTED] is, that all stakeholders from the last agreement originally were on that alias. Thank you very much for this clarification! Is [EMAIL PROTECTED] an OOo mailing list that one should subscribe to to learn as early as possible about Java related changes (configuration, class loader schemes,etc.)? ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Java 1.5 now minimal requirement ? (Re: [dev] RFC: java 1.5
Hi Kay, I did start the discussions regarding Java version, OpenJDK, baseline etc. on [EMAIL PROTECTED] Sorry for not announcing it here. Reason for [EMAIL PROTECTED] is, that all stakeholders from the last agreement originally were on that alias. Thank you very much for this clarification! Is [EMAIL PROTECTED] an OOo mailing list that one should subscribe to to learn as early as possible about Java related changes (configuration, class loader schemes,etc.)? exactly, full name is: [EMAIL PROTECTED] Hope that helps Yes, thank you *very* much (could already subscribe to it)! Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] FireFox 3.0 and OpenOffice-Add-on-Menu not compatible, how about a new version ?
Hi there, after upgrading to FireFox 3.0 the OpenOffice.org menu extension is Not compatible with Firefox 3.0 and therefore disabled. Are there any plans to update this little (and from time to time very helpful) add-on? ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] FireFox 3.0 and OpenOffice-Add-on-Menu not compatible, how about a new version ?
Hi Oliver, after upgrading to FireFox 3.0 the OpenOffice.org menu extension is Not compatible with Firefox 3.0 and therefore disabled. you can patch the extension's install.rdf: em:maxVersion3.0/em:maxVersion don't forget to delete the extensions.cache before you start again ... Thank you *very* much for this valuable hint! Now, just downloaded the xpi-module from https://addons.mozilla.org/en-US/firefox/addon/4102, unzipped it and found out that it had already the following entry: em:maxVersion3.0.*/em:maxVersion which indicated that it got changed already to fit into FireFox 3.0. However, FF was not able to find a newer version of the menu extension, when it automatically checked for one! Maybe one needs to change further version information in the rdf- and installation js-files as well? Anyway, being a very happy camper... :) Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Java 1.5 now minimal requirement ? (Re: [dev] RFC: java 1.5
Hi there, just noticed that running DEV300/m23 with Java 1.4 does not work anymore: - cut here - E:\rony\dev\bsf\src\bintestOOo.rex Exception in thread main java.lang.UnsupportedClassVersionError: com/sun/star/comp/helper/Bootstrap (Unsupported major.minor version 49.0) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) at java.net.URLClassLoader.defineClass(URLClassLoader.java:251) at java.net.URLClassLoader.access$100(URLClassLoader.java:55) at java.net.URLClassLoader$1.run(URLClassLoader.java:194) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.bsf.util.EngineUtils.loadClass(EngineUtils.java:385) at org.rexxla.bsf.engines.rexx.RexxAndJava.javaCallBSF(RexxAndJava.java:3191) - cut here - Going back to this list, the last comment on RFC for Java 1.5 was: Mathias Bauer wrote: Hi all, Christoph Neumann wrote: Kay Ramme - Sun Germany - Hamburg wrote: Stephan Bergmann wrote: Malte Timmermann wrote: My point of view: Most people agree that OOo mustn't loose (meta) data when Java is not available, but plug ins for working with meta data can rely on Java. Changing OOo's Java base line from 1.4 to 1.5 is fine for most people then. AFAIK the current Java baseline is 1.3.1. That is correct, the (still) valid consensus regarding Java can be found here: http://tools.openoffice.org/policies/java_usage.html respectively the background: http://tools.openoffice.org/servlets/ReadMsg?list=jdkmsgNo=90 This document is aged four. Shouldn't we reconsider about this status? I think what we need is a list of complete and 100% free Java implementations on all relevant platforms and the Java version they are compatible to. Do we have one? Or do we have a volunteer creating one? Ciao, Mathias Not having noticed a consensus to have Java 1.5 as the required version for OOo (yet), I just was wondering, whether m23 is mistakingly built with Java 1.5 or whether from now on Java 1.5 would be the minimal version for OOo.And if the latter, what about newer builds of OOo 2.*, would they mandate at least Java 1.5 as well? ---rony
Re: [dev] VCL UI Rework
Hi Michael, On Fri, 2008-05-16 at 10:12 +0200, Juergen Schmidt wrote: whatever we will use in the future it will be important that we will have a GUI editor to make the design of new dialogs much more easier than today. Yep; absolutely - it's in the spec. and we have a quarter-functioning one already ;-) Ideally a replacement for the basic dialog editor and make it more general for internal development as well as extension development (includes Basic as it does today). Sure - ideally :-) ... cut ... A big request: please allow using scripts from any of the OOo supported scripting languages. TIA, ---rony
Re: [dev] Opening SXW files with OOo2.x
Hi Juergen, it sounds strange and we should analyze the problems. Can you submit an issue (component writer, sw) with an example sxw document attached. As far as i know no such problems are known so far and it would be interesting to know what happens. probably totally unrelated: yesterday I stumbled over a four page Word document that misses the content of the cells in the first column of a Word text table, when opened with 2.4. or 3.0beta (opens o.k. in Word 2003 and with WordPad). Would it make sense to open an issue and supply the document as a testcase? If so, whom (acronym) should I try to assign such an issue? ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] RFC: java 1.5
Hi there, Charles-H. Schulz wrote: Le 4 mars 08 à 15:23, Frank Schönheit - Sun Microsystems Germany a écrit : Hi Hubert, I don't know if you have noticed, but they are been several request from people to have OOo ported to embedded devices like Maemo and iPhone, for which Java is likely to be an even bigger problem. Come on. When we ever port OOo to one of those platforms, Java is one of our smallest problem. For the concrete case, this means that any other third-party library we could use will most probably also not run on those platforms. So effectively, you say don't use third-party libraries. So without judging the concrete case, the argueing with possible future ports to platforms without Java is simply not a valid point, IMO. I am personnaly more interested by the aspect related to freedom (as in speech) on this question. Many of them have been sorted, but freedom is also freedom to leave and freedom not to rely on one specific platform, although java can of course be a compelling choice. So the question I have now can be summarized in one word: 'adherence' . Adherence to Java, maintenance, adherence to a VM, breadth of alternatives (not just for java), etc. I am putting myself in perspective of the ToolKit as well. Any thoughts? Well, as long as a discussion about Java and/or C/++/# is not a religious one, then one may observe that * Java has become ubiquitous, practically all PCs have it installed, i.e., it is usually available on any PC o one of the major reasons seems to be that WWW mandates Java because of numerous Java applets in the field o it has been available (and used) on mobiles for quite a few years now, just look at the Java games there (i.e. ME based), but also regular sized Javas available for Symbian based mobiles + Google's Android is an practically a purely Java based mobile operating system using Apache's opensource Java named Harmony (which in itself is at least at the Java 1.5 level and has already most of Java 1.6 implemented), the first such mobiles are expected to hit the market by the end of this year * Java indeed fulfills the promise to run everywhere; I know from experience as I am a person who has added the ooRexx scripting language to OOo via the OOo Java-based scritping framework; ooRexx itself is written in C++, the scripting interface in Java (using JNI, the Java native interface that allows bridging C/++ with Java). The Java part of that support (which is a generic one, i.e. ooRexx can interface with any Java object, totally independent of OOo) has *never* in the past *eight* years of its existence changed. This means, that in the original support that was created for OS/2 (yup!) and Windows, all the ooRexx examples employing Java objects (including GUI applications originally developed under OS/2!) run *unchanged* on Linux and MacOSX! FWIW, I cannot state the same for C/++ part of the JNI interface as every platform usually has its favored compilers yielding all sort of funny #ifdefs which have been growing over time. * Coming from an academic background there is another interesting aspect to Java: today, it is the most widely used programming language to create applications in the world, and by far the most widely taught computer language (employed even outside of specialized informatic studies) in the world. This means that it is quite probable (and can be witnessed following the OOo e-mail lists) that there are people joining OOo development with Java that otherwise would not stand a chance to help (short of having the necessary C/++ skills). Taking all of this into account it seems to be a very attractive goal to create (or employ thired party) libraries in Java as that would truly help to cut down porting costs, as usually you won't have no porting costs with Java. E.g. look at the XML processing Java libraries that are also used in OOo. As OOo already deploys Java in a number of areas in addition, I would in any case support the usage of Java for adding new functionality to OOo. Even, if that would mean that Java becomes a mandatory part for any OOo distribution. This just would reflect the reality of the environments under which OOo has been running already and on which Java has been deployed already independent of OOo! Just my 2 cents... ---rony
Re: [dev] Multilanguage documents
Christian Lohmaier wrote: Hi *, On Nov 11, 2007 3:54 AM, jonathon [EMAIL PROTECTED] wrote: Rony wrote: FWIW: MS Word has been having that ability for quite a few versions now. There one would use the Language tab on styles to define what language it is used for (on that dialog one is able to turn off grammar- and spell-checking). How is that different from implementing language specific styles in OOo? Please don't confuse KAMI's feature-request with the stuff described in this excerpt. Did not realize that! Of course you can already assign different languages to different parts of your document and that language will be used for spell-checking, hyphenation and will affect things like autocorrect/autoformat (replacement of typographic quotes for example) Tsk, thank you for pointing that out. Being somewhat accustomed to MS Word, I looked into the wrong area in OOo to find that (just found it to be a drop-down field on the Character- resp. Font-dialog)! - if you choose the language none, no spell-checking, hyphenation is performed. Well, that would be *quite* different from being able to assign a specific language (important, to be able to identify/extract text in a certain language) and determine that that should not be spell-checked, hyphenized or Grammar checked. ---rony
Re: [dev] WARNING: Do Not Install IBM Lotus Symphony (Beta)
Allen Pulsifer wrote: To all the OpenOffice users who might be interesting in trying out IBM Lotus Symphony (Beta): DO NOT INSTALL IBM Lotus Symphony (Beta) !!! I tried it out. It took over all of my OpenDoc file associations, without warning, and installed itself into a handful of other file associations. IT HAS NO UNINSTALLER, SO THESE CHANGES CANNOT BE EASILY REVERSED! Basically, it made a mess out of my registry. Its taking me about an hour to fix it. WARNING: INSTALL IBM Lotus Symphony (Beta) AT YOUR OWN PERIL! Well I tried it out on Windows too and I could install and de-install it, using the Software option in the System folder. However, some associations (I think ODT or ODS) did not get restored correctly. Start-up times are abmysal in this beta drop, not sure whether IBM is able to improve that. ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] commercial use of oo api (license issue)
Hi Bartosz, Bartosz Sokolowski wrote: And what do you think about that: Yes, you may use OpenOffice.org binaries (the usable application) for commercial use. You may freely distribute it to any user. Please go to our download page to find the latest releases. (http://www.openoffice.org/FAQs/faq-licensing.html#8) The only difference is that I'm using not only binaries, but I also needed to change OO source in few places. I also use those 5 jars that I mentioned. i took them from the OO directory (under Windows they usually are here: C:\Program Files\OpenOffice.org 2.2\program\classes), but can I be sure that there are released also under LGPL? I'm asking because some parts of OO have different Third Party Licenses. Thanks for your advices. If you change anything in the OOo source code and distribute the result (in binary form) then you are obliged to publish/distribute the sources (with your changes) as well, such that others become able to perhaps take advantage of your improvements/changes. You may find a few interesting bits here: http://wi.wu-wien.ac.at/rgf/diplomarbeiten/Seminararbeiten/2007/200701_Boehm/20070123_BoehmPatricia_FOSS.pdf. Also http://www.opensource.org/ is a good place for researching all sort of OSS licenses (on the left column), [L]GPL's home would be at http://www.gnu.org/. HTH, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] PresentationClock
Hector Socas Navarro wrote: Oops, sorry, I just read that attachments are not allowed in the list. Here's my message again without the attachment (a screenshot can be found in the same directory as the code): Hi folks, I've written a little program in C to use in combination with Impress that will help presenters keep track of time. Here's an excerpt from the README (I'm also attaching a screenshot with this message): I wrote this software to solve a little problem I've always had when making presentations with either OpenOffice Impress or MS PowerPoint, namely how to keep track of time. Sure, these programs have an option to automatically advance slides based on some previous rehersal timing but I find that completely useless. What I wanted to have is a way to time the whole presentation with a simple visual aid to tell me whether I'm on track, behind or ahead of schedule. This is exactly what PresentationClock does. Basically there are two modes of operation. In the record mode, PresentationClock will track the timing of your rehersal. Then during the actual presentation it will display a little clock showing if you're behind or ahead of schedule and by how much. I find this feature extremely useful in my work. The source code and an executable can be found in: http://download.hao.ucar.edu/pub/navarro/PresentationClock/ Very nice. Also, there exist OOo snippets to produce guide-posts and various visual indicators about the progress of a presentation which is adjustable on the click of a mouse in case a presentation got changed (added/removed slides): Original Message Subject:[api-dev] Announcing OpenOffice-Impress-Snippets in ooRexx ... Date: Wed, 15 Aug 2007 21:30:42 +0200 From: rony [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Original Message Subject: Announcing OpenOffice-Impress-Snippets in Rexx ... Date: Wed, 15 Aug 2007 21:27:34 +0200 From: rony [EMAIL PROTECTED] Organization: University of Economics and Business Administration, Vienna, Austria Newsgroups: comp.lang.rexx Original Message Subject:[RexxLA] Announcing ooImpress-Snippets in Rexx ... Date: Wed, 15 Aug 2007 21:23:21 +0200 From: Rony G. Flatscher, VP [EMAIL PROTECTED] Hi there, since this week theOpen Office Snippets for the module impress (presentation module of OpenOffice.org) are available via the official OOo Snippet page at http://codesnippets.services.openoffice.org/Impress/ooRexx.xml. As the Rexx syntax is like pseudo-code the snippets (little nutshell programs that stress a particular aspect of programming the module) can be easily understood. The interfacing is carried out using OOo's Java interfaces (using BSF4Rexx), therefore these code examples would also be usable directly for Java as well. The snippets possess links to the official OOo IDL documentation, which allows to research the API environment of the snippet. All of these snippets were created in the course of a seminar paper at the Wirtschaftsuniversität Wien (Austria, Europe) and the paper is therefore available (in English) in form of a PDF file: http://wi.wu-wien.ac.at/rgf/diplomarbeiten/BakkStuff/2007/200706_Gundacker/OOoImpress_GundackerDominik.pdf. All of the snippets are available as a single zip-archive from that site as well: http://wi.wu-wien.ac.at/rgf/diplomarbeiten/BakkStuff/2007/200706_Gundacker/OOoImpress_macros_GundackerDominik.zip. HTH, ---rony P.S.: Further links: * ooRexx (Open Object Rexx, FOSS): http://www.ooRexx.org * BSF4Rexx (Java interface for Rexx, includes additional support for OpenOffice.org a.k.a. OOo): http://wi.wu-wien.ac.at/rgf/rexx/bsf4rexx/current/ or a newer beta at: http://wi.wu-wien.ac.at/rgf/rexx/bsf4rexx/old/2007/dist.20070707/ --- end of message -- The PDF-files give screenshots of the various guidepost and indicator types. HTH, ---rony
Re: [dev] OOo_2.3.0rc2_20070905 and Scripting Framework: were there any changes there ?
Hi Jürgen, yes, the way how extensions are loaded has changed a little bit. Related to this change the search of dependent jar becomes more important. Extensions are now loaded with their own classloader and you have to specify dependent jars in the manifest file of your extension jar. I see! I can assume that in your case your ext jar depends on some scripting framework jars and that they are not found automatically. As I am using the OOo scripting framework itself there is the dependeny to program/classes/ScriptFramework.jar, which is OOo's stock scripting framework. Sounds like a problem and we have to think about it. I am only guessing but it seems that we need something special handling for this kind of scripting extensions. Well, if the class loader honors all OOo supplied jars (i.e. all jars in the classes subdirectory) as previously, then this would not be a problem. How would I state OOo deployed jars in the manifest file (i.e. to point to program/classes/ScriptFramework.jar wherever the program dir resides on a filesystem? (Sorry, if this is a rooky question, but I have not stumbled over that yet, or my memory fades already... ;) ) you should submit an issue for that problem. Should I assign it to someone already? Thanks! ---rony P.S.: As a sidenote: it would be possible with the help of Apache's upcoming BSF 3.0 (in beta at the moment) to employ javax.script (introduced with Java 6) on earlier versions of Java (BSF 3.0 is compiled for Java 4). This would have the benefit that the number of usable scripting languages for OOo would be enhanced tremendeously. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo_2.3.0rc2_20070905 and Scripting Framework: were there any changes there ?
Hi Jürgen, By the way you can add the scripting framework jar file manually to the classpath and can check if it works. Just tried it: does not work. Also tried using Rene Engelhards suggestion (UNO_JFW_CLASSPATH_URLS), unfortunately to no avail. Will file an issue. Thanks again for your quick answers! ---rony P.S.: Of course all OOo jars would be needed in addition that reside in the classes directory. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Filed as Issue # 81445 (Re: [dev] OOo_2.3.0rc2_20070905 and Scripting Framework: were there any changes there ?
Hi Jürgen, did submit the issue and set it to P1 (highest priority), as maybe other third party Java based components/extensions may be affected by this too. (Though P1 might have been to high.) Here's the URL: http://www.openoffice.org/issues/show_bug.cgi?id=81445. Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Filed as Issue # 81445 (Re: [dev] OOo_2.3.0rc2_20070905 and Scripting Framework: were there any changes there ?
Juergen Schmidt wrote: Rony G. Flatscher wrote: Hi Jürgen, did submit the issue and set it to P1 (highest priority), as maybe other third party Java based components/extensions may be affected by this too. (Though P1 might have been to high.) Here's the URL: http://www.openoffice.org/issues/show_bug.cgi?id=81445. see also http://so-web.germany.sun.com/iBIS/servlet/edit.ControlPanel?tid=i80100 http://so-web.germany.sun.com/iBIS/servlet/edit.ControlPanel?tid=i51803 as references. Thank you very much for these as well (at the moment the server name is not resolvable, will try it later)! ---rony P.S.: Gute Besserung for Stephan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] How++ (Re: [dev] How about .. . (Re: [dev] Develop macro recording as it ought to be for all modules ASAP !? (Re: Vá: Re: [dev] Disabl ed Record macro menu in Impress and Draw
by this? Or would it be more in the hundreds (which would make a big difference)? For the core-developers it would be the task to supply machine readable documentation of what the dispatch call does by supplying the matching UNO sequences. It would not (!) be a new (partial) implementation of the glue code at this stage! In order to do that documentation systematically there should be use-cases defined (e.g. search and replace, defining a shape, adding a new formatting rule, printing a selection, mail merge, exporting, importing, creating a link, embedding some object etc.) for which all of the dispatch calls get documented that way (which would be initially just a very small fraction of the dispatch calls). Then macro programmers who know UNO could come up with matching implementations in their macro language from this documentation (possibly automatically translating from the machine readable, and hopefully intelligently ;) structured docs to the respective language of interest, e.g. OOo Basic, Java, etc.). Just running such macros would then show quite quickly whether the documentation (UNO invocations matching the dispatch calls for a specific use case are complete/error-free, and if not, then even this group of people could jump in to help to fully/error-free document the needed steps in the UNO world to carry out the respective use case successfully). If such an endeavor was backed with a database where you would have the use-cases, the dispatch calls and the matching sequences of UNO based invocations in a neutral, structured, machine readable form, then one might even think about the automatic generation of macros/programs in a desired target language at the press of a button. :) (Besides, over time it would allow for cross-referencing and for many forms of analysis.) Initially it would be a documentation knowledge base, which may grow over time and cover all of OOo, or at least all building-blocks dispatch calls needed for macro recording. At least we would arrive at use-cases how to achieve certain tasks in OOo with the help of UNO, and even have macro code for that generated! (Of course once the mapping to a certain language could be successfully established, then it might become possible over time, to generate even the new glue code from it.) Again, this is pure speculation and could be totally undoable, but maybe not. Ceterum censeo, new macro recording ... ? ---rony
Re: [dev] How about ... ( Re: [dev] Develop macro recording as it ought to be for all modules ASAP !? (Re: Vá: Re: [dev] Disabled Re cord macro menu in Impress and Draw
would not be invocable via UNO? A reverse mapping should be establishable then as well in this case, even if that is a 1:N mapping (i.e. a C++ function/method gets invoked from different UNO types), it would at least allow for narrowing down the UNO types, and it could be possible that from the context one could even narrow them down further. But again, this could be total rubbish and not worthwhile to pursue... BTW: do you plan to be at the OOoCon in Barcelona? Unfortunately, no (I do not get funding, if I just attended, i.e. not doing a presentation of some sort). Maybe next year. Talking about this face to face with some code to look on (and hack ;-)) would be much easier. Yes, that would be a good idea. However, I would need some time to refresh and brush-up my C++ knowledge beforehand (I used to teach it, but that is now many years ago, such that my C++ skills have become quite rusty unfortunately; enough is remaining to read existing code and knowing how to edit and compile it if there is a compelling need; but the knowledge about many of the C++ idosyncrasies has faded). --- Ceterum censeo, macro recording ... :) Regards, ---rony
Re: [dev] How about ... ( Re: [dev] Develop macro recording as it ought to be for all modules ASAP !? (Re: Vá: Re: [dev] Disabled Re cord macro menu in Impress and Draw
Mathias Bauer wrote: Rony G. Flatscher wrote: But there must be a mapping available which maps from UNO to C++ as otherwise the C++ code would not be invocable via UNO? Of course: this is the Dispatch API! The UI elements use die Dispatch API to call a method in a UNO object implementing com.sun.star.frame.XDispatch. This is the only UNO based call involved. The implementation of this object only uses pure C++ calls inside, nothing based on UNO APIs, neither in-process nor remote (urp). But then, wouldn't this also mean that this Dispatch API is excercised by all OOo modules then, including Draw/Impress, or is it the case that for using that API some of the module-dependent (C++ implemented) UI elements still need to be programmed accordingly? But we are talking about recording the other API that an experienced OOo API developer would use to perform the same task. And this API would be a completely different one. Right. If I have some time I will try to put some code snippets into the wiki that should demonstrate this. Would be very interesting in any case, but your points seem to be already very clear. A reverse mapping should be establishable then as well in this case, even if that is a 1:N mapping (i.e. a C++ function/method gets invoked from different UNO types), it would at least allow for narrowing down the UNO types, and it could be possible that from the context one could even narrow them down further. The reverse mapping that we can do is what the current macro recorder does: all received dispatch() calls are recorded. Hmm, would it be conceivable then to come up with a static table of dispatchable user-actions with a sequence of UNO API invocations that would be needed to be excercised such that for recording purposes this list could be used in addition, recording the values of arguments and results and so on. Or with other words, for every dispatch have an independent, alternitve thread of creating UNO pseudo-code necessary to arrive at the same functionality, stating pre- (which UNO objects, methods, argument values) and post-conditions. Maybe even including branch statements, or with other words, small (commented) pseudo-code segments that could be used to map to a concrete language later on. Either being editable to correct or supply addtional code/information. Even if it is not perfect and may contain omissions or incomplete information it may generate UNO based code that needs a little bit of massaging, it would be so much more and a starting point that really may drive up productivity. (Obviously looking for a Pareto solution, i.e. 20% effort for covering 80% of the needed functionality, leaving the missing 20% to the UNO/OOo savvy programmers.) Power end-users would be able to create that skeleton then rather easily, needing UNO/OOo acquainted programmers to turn it to a running macro. Ceterum censeo, macro recording ... :) ... esse delendam? ;-) ... esse implementam ! :-P Regards, ---rony
[dev] How about ... (Re: [dev] Develop macro recording as it ought to be for all modules ASAP !? (Re: Vá: Re: [dev] Disabled Record macro menu in Impress and Draw
be concluded that for C++ urp is not necessarily excercised; if so, would it be possible to define a mode in which even C++ would use urp (maybe only temporarily for the duration of the recording session)? + idea aspect programming: it has been *quite* some time that I really worked with C++, and because of that I am not acquainted about the state of the art of aspect programming for C++. The idea would be as follows: inject recording code (maybe if not at runtime than with scripts right on the C++ source code) at the top of a function/method recording the object, name, arguments, and inject recording code everywhere where return values exist in that function/method. * What should be recorded and how should it be encoded? o The starting point (i.e., whatever macros already get supplied with if invoked for an OOo document) information. o Assuming that the user interactively starts recording a macro all invocations of functions/methods thereon caused by the user should be recorded. Whatever function/method invocations occur because of that in the background is not interesting. [Even if a mouse-moving action of a user gets recorded with possibly hundreds of function/method invocations, these should be recorded (it would be eventually possible with heuristics to cut that amount down).] Hence assuming that user interactions occur at level 0, each invocation of a method/function would bump up the level by 1 (done by the recording code), only level 1 invocations would cause the invocation to be recorded. o The object, the method, the arguments and the return value should be recorded. If an object gets used later as an argument or as the target of invoking a function/method it should be possible to learn that that object is already known in the recording session and merely re-used. o The representation of the recorded invocations should be as language neutral as possible (encoded as byte-code, as XML-text, etc.), such that it would be possible for any language to learn everything needed to create a program of it that would replay the invocations that the user caused. In any case recording of type information (as fully qualified IDL names) and UUID of the objects in the recording session (in order to find out which objects are the same, i.e., are reused in the course of the macro recording) would be needed. Again these are just coarse ideas (ideas/thinking would be needed for dealing with dialogs and the interaction of users there, which seems to be one of the challenges; but depending on the dialog architecture one might be able to figure out the fields and values at popup-time and the fields and values at popdown-time, resp. whether a dialog was closed with an undo action, i.e. the invoking of the dialog could be dismissed totally from the recording). Not knowing the inner working of UNO, I have no idea what problems may be hit (and would have to be solved). But at least at this coarse and unspecified level it may help to find other means/ideas/concepts to define a new macro recording framework that is feasibly implementable as quickly as possible. Would in theory any of these ideas allow a workable solution in your opinion? Not having all OOo modules equipped with macro recording would pose a constant (strategic) problem. (What I see about power end-users doing with MSO macro recording is very impressive and locks them into MSO.) /begin|end opinion, feelings, not quotable as facts ---rony
[dev] Develop macro recording as it ought t o be for all modules ASAP !? (Re: Vá: Re: [dev] Disabled Record macro menu in Impress and Draw
Hi there, the threads relating to macro recording abilities of OOo are very interesting. I have been somewhat puzzled about the conclusion that OOo should *not* have a macro facility at all and that the existing ones should be removed. The reason being that it would be too much effort for the expected benefit (see below)! Now this is puzzling for me for various reasons, especially in the context of typical end-users using OOo. Without a macro facility they have *no* chances whatsoever to be able to automate recurrent (business process) tasks on their own. They either have the choice of repeating (possibly cumbersome) over and over all the steps necessary to come up with a recurrent document, or they need to find someone who would be able to create a program for them to automate the recurrent functions they need. And here the simple truth is: there is almost no-one around who would have the *slightest* idea of how to automate/program OOo. Looking further for professionals is difficult to find ones, and if you find ones then you must be very, very lucky, if they have free resources that they sell/rent for an affordable price. Or with other words: forget it, rather repeat recurrent tasks by hand over and over again! This scenario does not look like an attractive or future safe one to me. Especially, if you compare this with Microsoft's Office (MSO) where it is extremely easy for end-users to record macros, in practice this is a no-brainer for them! As a result it is a) easy and b) cheap for MSO customers! Also, recorded macros can be adjusted quite easily, if an end-user has a coarse understanding of programming. Not seriously planning for a macro-recorder facility is a *quite* a *deadly* strategic error IMHO. MSO runs rings around OOo in a very important application segment! And MSO will be able to do that eternally, given any misisng plans to implement a macro recording facility for all modules. Rather than tackling this incredible omission immediately to fill this incredible hole, the undisputed conclusion seems to be, well we can't do it now, so we don't do it, and best, we ought to remove the existing macro recording as it was not done the way it should have been done from the beginning. Again, for an end-user perspective this is a glaring hole, making MSO truly much more attractive for their own daily work. Hence OOo *must* get macro-recording as it should be done for *all* modules as quickly as possible, if OOo should win and take over the hearts of the OOo users, especially the huge group of end-users sitting in all of these departments that should be migrated from MSO to OOo! Just my 2 cents. ---rony P.S.: If designed and done right, then macro recording should be feasible for interacting with/using any UNO service object in a language neutral manner, such that the generable macros could be created for any of the desired target languages of the users, OOo Basic, Python, Java, BeanShell, ooRexx, and the like. E.g., if I knew what the initial environment was (already there for macros) and what interactions (API invocations with used arguments) took place, then I would be able to (easily!) create from that an ooRexx program that would be able to replay all those API invocations. I am sure that Andrew would know and be able to do the same vor OOo Basic, and everyone else acquainted with UNO and another scripting language would be able to generate the appropriate code in their chosen scripting language. Mathias Bauer wrote: Andrew Douglas Pitonyak wrote: Even better, will a new and improved macro recorder be implemented? I do not remember seeing one in any road map, but I might have missed it. A new+improved macro recorder (I assume you mean a recorder that uses the real API and not the dispatach API) would be possible only by completely rewriting all glue code between the controls and the document core. This is very unlikely to happen. Why is that so? A recorder can record only API calls that are played. The only API calls that currently are played are the dispatch API calls. If you wanted other code to be recorded we would need to use (play) them in the code executed by e.g. the code that is executed when a menu or toolbar control is selected. And while we are at it: Kálmán Szalai wrote: Thank you for the information. Are you planning to reimplement this part and make it available under Draw/Impress? There are no plans to implement that. If I had the choice I never would have done it for Writer and Calc also as the current macro recorder is not what people really want and the real thing is just too much effort for the expected benefit. The resources we invested for that can be used better for more important things. Ciao, Mathias
Re: [dev] Bug in determining Java type for UNO_LONG properties ?
Hi Jürgen, Problem: using a property's' Type attribute (prop.Type) one works with a com.sun.star.uno.Type object (cf. http://api.openoffice.org/docs/java/ref/com/sun/star/uno/Type.html) it seems that for UNO_LONG types (prop.Type.getTypeClass() returns an UNO_LONG TypeClass object), whereas prop.Type.getTypeName returns the string name long instead of int. you get always the UNO type name and not the mapped name for a specific language binding. Thank you very much for this clarification! The documentation of com.sun.star.uno.Type is not totally clear for me, therefore I would like to discuss this, before really going out and filing an issue (possibly wrongly). you can submit an issue for the docu if you want Hmm, maybe this is not warranted (saving resources for other issues). ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Bug in determining Java type for UNO_LONG properties ?
Hi there, tried to find an entry on this in the issue tracker, but have not been successful. Hence, first asking whether this is a bug in the Java interface to UNO or a misconception on my side. Problem: using a property's' Type attribute (prop.Type) one works with a com.sun.star.uno.Type object (cf. http://api.openoffice.org/docs/java/ref/com/sun/star/uno/Type.html) it seems that for UNO_LONG types (prop.Type.getTypeClass() returns an UNO_LONG TypeClass object), whereas prop.Type.getTypeName returns the string name long instead of int. As a result, using this information to cast Java types to the corresponding UNO type yields a type error as supplying java.lang.Long objects for UNO_LONG properties is not possible, rather java.lang.Integer objects need to be supplied for them. The documentation of com.sun.star.uno.Type is not totally clear for me, therefore I would like to discuss this, before really going out and filing an issue (possibly wrongly). Any comments/hints/insights? ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
