[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] 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] 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
[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
[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
[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
[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] 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
[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
[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
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).
[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] [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
Hi Matthias, Mathias Bauer wrote: 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? The Dispatch API is the same in all modules - but this is a generic API and the real action lies in the command names and paramters. All objects have the same interface to receive commands but they differ in the commands they support and - in case of Draw/Impress - also in the degree of how good their implementation actually is. In Draw/Impress parameters are mostly not supported at all and they are essential for playing recorded macros. That's enough for calling the Dispatch API from the GUI (where usually no parameters are sent) but is a killer for playing macros using the API. Besides that: this is only the playing side, in Draw/Impress the recording side even looks worse (remember the rule set for recorder support I posted earlier). Given all of your information, I very much tend to believe that. ;-) 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. You have described reimplement the glue code with other words. Yes, of course you can reimplement each and every dispatch call by using UNO API calls. You can do this in the glue code itself (thus replacing it) and record these calls or you can have a parallel implementation somewhere else as you described or Paolo Mantovani already did for some Calc dispatches. But it's a reimplementation in all cases! The difference only is that in your case the original code is not replaced but its effect on the document is achieved differently. This has an advantage (no regression risk as the original code is preserved) as well as a disadvantage (OOo's size will grow considerably). And it's time consuming in every case. Yes, but one would have to start out *documenting* what should happen in the UNO world to match a particular dispatch call in any case! Even if you started out without the existing dispatch calls you'd still be forced to document/define what should be done in UNO to map what is sought for in the C++ implementation. Or with other words: you can't get a new macro recording in place without efforts! The question would be how to achieve this as quickly and resource-saving as possible, if you are serious in creating and supplying a full featured macro recording eventually (hopefully within one, two years). 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. Now we are at the point where we started: writing down the correct set of UNO API calls for each dispatch call will first force us to deliver the missing APIs and types and then will take years to implement the calls. We have thousands(!) of dispatch calls to implement. Some of them also depend on internal states. The command .uno:Delete e.g. must be implemented completely different depending on what is selected. Not sure (again not knowing anything about the inner workings, hence pure speculation) about this conclusion. How many dispatches are generated via the GUI resp. via the current macro recorder, are these *really* thousands of different dispatch calls that are *directly* caused by this?
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
Hi Matthias, So here the rule if everything is important nothing is important applies. Right! In result the project members must decide by themselves. Without any data backing up that 2 man years development time for improved automation support (plus QA etc.) will please more users than those who can become pleased by what we can do instead of this (improving usability, filters, performance etc.) I don't see it happen. That is really the point: how to assess what is (really) important for what purpose. Current users of OOo have a high interest in the latter, i.e., constantly improving the current OOo, filling felt gaps here and there; like Base now getting a great reporting facility (which is very important, needless to say). Of course macro recording would improve the usability for current OOo users as well, helping them automate their tasks (business process steps). However, my main-focus would be about unlocking MSO power end-users, who use macro recording (and then have someone else alter the generated code to suite more their particular needs, or quite a few times being able to edit the recorded code themselves in little corners and edges), which would be an ongoing and strategic goal. Of course there are many, interesting, worthwhile RFEs out there, which should (all) be implemented. However, that fact should not lead to the wrong conclusion that macro recording was not that important at all. Sorry, that wasn't the impression I wanted to create. This is true only in the meaning I wrote: if everything is important ... If we saw it as totally unimportant we wouldn't have tried it at all. Yes, I thought so (really!), but at the moment it seems to be the case that it is put on the back-burner, short of viable trails to achieve full macro recording with the scarce resources at hand. Both are independent, important development routes. Macro recording in this context is of strategic importance. In the past OOo/SO developers have appreciated that and implemented it (even if it was done in a way that today does not appear to be appropriate). IMHO the Dispatch API approach is a good one in case we wanted to target only the automaters and in fact this was our intention. Perhaps we should have created binary macros only, without showing any source code. In fact that was my proposal but that wasn't well received at that time. That would have explained much better that we never wanted to provide that real macro recorder that we think we can't deliver in a reasonable amount of time. Either one would be great, a binary solution, if well-thought out upfront would allow to write later programs that should be able to create source code from the binary representation in any of the languages that support interaction with OOo (i.e. while crafting the binary specs, also information should be recorded for the purpose to allow transcriptions later). (Speculation, of course!) It looks to me that at one point in time it was common knowledge among the developers that the macro recording should be done to allow replaying it via the dispatch interface was not optimal and should be eventually replaced. Not really, as I wrote, the original intention indeed was to create an automation tool, not a developing macros teacher. Yes, the automation tool would be paramount. However, thinking about allowing the recorded macro to be transcribed to a macro language later should not be ruled out, as it would allow for many applications of it (as can be seen with power end-users in the MSO world). This transcribing would probably be possible to members of the community, whereas the macro recording funcitonality itself is something which probably only the core developers would be able to master efficiently and completely. (snip) I'm afraid that reading and understanding your thoughts will require some time. But a first glance showed me that you think about intercepting calls (urp). As this will require UNO calls that could be bridged I'm not sure if I made myself clear enough. So before I dig into your ideas deeper (and I will really try to) please answer these question: Do you agree that my explanation on the wiki page made clear that whatever we do we can't build upon UNO and UNO APIs as this would require a complete rewrite of our glue code that currently does not use any UNO runtime or UNO API calls? In a 3-tear-model that would be the middle or basic interface level (BIL) or however you want to call it. Yes. (But again, I am not aware of the inner workings and architecture put in place, and have no knowledge about what would be still conceivable and what would not be conceivable at all.) So what we have is the level of pure C++ function calls. IMHO there is nothing you can record and play, you always need an object model to work on and that's UNO. But there must be a mapping available which maps from UNO to C++ as otherwise the C++ code
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
Hi Matthias, Of course Draw/Impress has a macro facility but not a macro recorder and nobody wants to remove this facility. I see that this is what you meant - but please let's be accurate, rumours spread faster than you can imagine and next week you can read somewhere that we are going to dump Basic macros in Draw. ;-) Yes, you are right! Of course Draw/Impress does have a macro facility, but not a macro recorder! From here on everything is a totally personal opinion and may be erroneous due to lack of understanding/knowledge of some or all of the underlying technologies/infrastructures. begin opinion, feelings, not quotable as facts Just my 2 cents. I'm afraid that 2 cents won't be enough, but in case you could invest 20 million cents we could think about implementing the dispatch macro recorder in Draw/Impress and fixing the existing one in Calc and Writer. I doubt that it would be possible with less effort. There are still much more areas in OOo where this investment is placed a lot better. This is This is what I object to: that macro recording was not really that important. In the contrary, macro recording is of utmost importance for end-users who wish to automate their businsess processes i.e. record re-curring actions and re-play them later, without any need of knowing how to program! Without end-users no need for other technical improvements, without such an important building-stone feature MSO aficionados can quite easily keep OOo off the door. what too much effort for the expected benefit means. In the same time you can implement much more things that much more people need. Of course there are many, interesting, worthwhile RFEs out there, which should (all) be implemented. However, that fact should not lead to the wrong conclusion that macro recording was not that important at all. Both are independent, important development routes. Macro recording in this context is of strategic importance. In the past OOo/SO developers have appreciated that and implemented it (even if it was done in a way that today does not appear to be appropriate). (Speculation, of course!) It looks to me that at one point in time it was common knowledge among the developers that the macro recording should be done to allow replaying it via the dispatch interface was not optimal and should be eventually replaced. Then Draw/Impress got developed further and macro recording was left out, because the existing technology was not optimal, but no alternative has been established. At the end (today) it looks as if the snake has bitten its own tail, and macro recording is in agony (downgraded to unimportant/not worthwhile in the mindset of some/all developers). But this simple recorder still isn't the real recorder that developers and development newbies want, they want a tool that teaches them the real OOo API (not the Dispatch API), not a simple automation tool. I have written a wiki page http://wiki.services.openoffice.org/wiki/MacroRecorder that describes the situation. Please everybody interested in this read it, and read it completely before you reply. If something is unclear of if you think that something is wrong please let me know it. Thank you *very* (seriously!) much for your efforts and explanations there! I hope that this will make clear where the problems are and why it would be such a huge effort to provide a real API macro recorder. Hmm, please take the following just as an attempt (maybe a poor attempt) to think the impossible: * Tabula rasa: assume no macro recording were present at all, how to add that functionality as quickly and effortlessly as possible? o As we have macro recording in some modules and not in others, why not attempt to start out in thinking from nowhere (pretending it did not exist yet). o The following two ideas are just ideas, because I do not really know the internals of UNO/OOo, I just have an outsider's view, which many times is a bird-eyes view (drawing concepts and assumptions from earlier SOM/DSOM/CORBA). The general idea is that some means is added that would indicate that some new recording mode is active or inactive, a call level and an object to use to record the invocation and returned value), and if set to active recording it should take place. + idea urp: in the case that each UNO/OOo related request/invocation of a method/function needs to be dispatched via urp, possibly applying marshalling, then why not create the recording code there: it would be possible to learn which object's method with which arguments has to be dispatched, and also what return value, if any, would be returned # Of course, from your Wiki page it may be
[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]
[dev] Seeking help/ideas on making com.sun.star.comp.helper.Bootstrap work on all (Linux) distributions ...
Hi there, it has been my understanding that the com.sun.star.comp.helper.Bootstrap class and its bootstrap() method are meant to allow bootstrapping OpenOffice in an easy manner/fashion on any operating system. As I have reported, on some Linux distributions that I have come to look at, the bootstrapping using com.sun.star.comp.helper.Bootstrap does not work! In the e-mails discussions in this group the reason was seen in a directory structure that would not structured the way that OOo (the helper class?) would expect it to be and hence would not be able to find the necessary pieces to get OOo started up. As being able to start OOo easily from the commandline *is* very important for many reasons it would be therefore very important to be sure that the helper class (OOo itself?) can successfully work on all distributions and succesfully start-up from any configuration. Especially, if these distributions do re-package OOo in a standardized way it seems, which has become state of the art on those distributions! --- In the meantime I was able to get in contact with Rene Engelhard, who has been packaging OOo for Debian according to the documented OOo rules, but in the process has been able to follow the standardized Linux installation rules. This is (with his permission) what he wrote: And this directory structure *IS* intact. we have ooodir/program where all libs are and we have oodir/program/classes (which indeed get changed, though as it's a symlink to a sane location following the standard. But the path is changed in the OOo configuration, too to not look in classes/ but in /usr/share/java/openoffice). I even bit into the bullet and added /usr/bin/soffice which apparently is needed for making the bootstrap thing work.. So it seems to me that Rene tried hard to create an OOo distribution which adheres to both, the OOo and the Debian standards. However, it seems too, that using com.sun.star.comp.helper.Bootstrap's bootstrap does not work, as it is not able to find soffice! :-(( --- Being stuck right now, I would request some suggestions/help on how to proceed from here in order to make sure that the helper class is truly able to startup OOo on any OOo installation that adheres to the installation rules (which seems to be the case with the Debian package). It would be quite awkward, if the only resolution at hand would be to advise people to rip off an OOo installation which adheres to its platform standards, and install the single-tree'd version that can be downloaded from OOo's home, as this would imply that in reality there was no freedom to adapt the OOo installation tree according to the rules of the host system. Thankful for any ideas/hints/help! ---rony
[dev] An example program that should work on all platforms from the commandline ... (Re: [dev] Seeking help/ideas on making com.sun.star.comp.helper.Bootstrap work on all (Linux) distributions ...
Hi there,
the following example program runs on many installations/platforms.
However, it *should* run flawlessly on *any* OOo installation:
cut here (CreateTextDocument.java))
import com.sun.star.beans.PropertyValue;
import com.sun.star.comp.helper.Bootstrap;
import com.sun.star.frame.XComponentLoader;
import com.sun.star.frame.XDesktop;
import com.sun.star.lang.XComponent;
import com.sun.star.lang.XMultiComponentFactory;
import com.sun.star.text.XText;
import com.sun.star.text.XTextDocument;
import com.sun.star.uno.UnoRuntime;
import com.sun.star.uno.XComponentContext;
class CreateTextDocument {
public static void main (String args[]) {
try {
XComponentContext xContext=Bootstrap.bootstrap(); // bootstrap UNO
XMultiComponentFactory xMCF=xContext.getServiceManager();
if (xMCF != null) {
Object
oDesktop=xMCF.createInstanceWithContext(com.sun.star.frame.Desktop,
xContext);
XDesktop xDesktop=(XDesktop)
UnoRuntime.queryInterface(XDesktop.class, oDesktop);
XComponentLoader xComponentLoader=(XComponentLoader)
UnoRuntime.queryInterface(XComponentLoader.class, xDesktop);
String url=private:factory/swriter;// define a
text document
PropertyValue noProps[]=new PropertyValue[0];// no properties
XComponent
xWriterComponent=xComponentLoader.loadComponentFromURL(
url, _blank, 0,
noProps);
// Fortsetzung nächste Seite ...
// ... Fortsetzung von vorheriger Seite
XTextDocument xTextDocument=(XTextDocument)
UnoRuntime.queryInterface(XTextDocument.class,
xWriterComponent);
XText xText=xTextDocument.getText();
xText.setString(Hallo Chemnitz, hier spricht Java!);
}
}
catch( Exception e) {
e.printStackTrace(System.err);
System.exit(1);
}
System.exit(0);
}
}
cut here
Setup the environment such that CLASSPATH points to the following OOo
jars (wherever they are installed on the target system): jurt.jar,
unoil.jar, ridl.jar, and juh.jar (sandbox.jar is not needed anymore,
starting with OOo v2.0).
Then compile the program with the Java compiler (javac
CreateTextDocument.java) and run the compiled class with java
CreateTextDocument.
Regards,
---rony
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] A few brief questions ad extension packages (Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Hi there,
sorry, was off for a week witohut access to e-mail, hence my late answer
(keeping the quotings so only this e-mail is needed).
Stephan Bergmann wrote:
Rony G. Flatscher wrote:
Hi Stephan,
, in the case of the ooRexx scripting engine:
* there is a platform dependent DLL/so which needs to be
accessible
(at the moment I copy it into OOoHome/program), so the library
is *not* an UNO-component, just a native library,
* there are three text files (actually ooRexx programs) named
BSF.CLS, UNO.CLS, UNO_XINTERFACES.REX which also need to be
accessible by ooRexx scripts (and for that reason I have to copy
them into OOoHome/program.
Which code accesses those files (the shared lib and the Rexx programs)
how, and why does it help to move them to the program directory? (If
it is clear how those files are accessed, there might be a way to
access them directly within the extension.)
Code which is invoked via the OOo scripting framework, here's what
happens:
* An ooRexx macro is invoked via Tools-Macro
* the Java support part for the scripting language uses BSF (Apache
Java archive) to load the Rexx interpreter (via the DLL/so
residing in OOHome/program) and supplies the script and makes the
arguments available to it;
I still do not understand how the DLL/so residing in OOHome/program
(lets call it X) is loaded. Is it supplying UNO services/singletons
and is thus loaded via the UNO framework?
Yes, the ooRexx script provider package for OOo adheres to UNO
(ScriptProviderForooRexx.jar) which invokes bsf.jar (an Apache.org jar
which invokes the DLL/so via JNI, which then invokes the ooRexx
interpreter).
Is it loaded from some Java code Y via System.loadLibrary? Is it
loaded from some native code Z via dlopen?
If an ooRexx script is run by OOo, then the ooRexx script provider
package (ScriptProviderForooRexx.jar) is used to dispatch the macro
using bsf.jar which uses JNI to load the [lib]BSF4Rexx.{dll|so}which
then will load the ooRexx interpreter and supply the macro for
execution. Such ooRexx macros need access to UNO.CLS (which itself needs
access to BSF.CLS and UNO_XINTERFACES.REX) to make it really easy to
interface with OOo. Placing the DLL/so and the ooRexx files (plain
textfiles) into $OOO_HOME/program makes the ooRexx script provider run
successfully, i.e., these files will be found.
Therefore I have been under the impression, that OOo sets that directory
($OOO_HOME) to the PATH (and maybe LD_LIBRARY_PATH on Linux systems?)
environment variable, as otherwise these files could hardly be found.
* the Rexx interpreter executes the script which itself calls
UNO.CLS (specific UNO/OOO support, which itself uses
UNO_XINTERFACES.REX), which calls BSF.CLS (bridge to Java); all
these scripts are plain text files and are found in their location
(OOHome/program).
*Why* are they found in the program directory?
Good question (but I am *very* happy that they are found!) !
:)
Does the Rexx interpreter (is that the library X above?) look next to
itself for them? (That is, if the Rexx interpreter were instead
located in your extension, would those text files automatically be
found in your extension, too?)
The Rexx interpreter is not placed in the script provider package, but
accessible globally (on Windows it is installed for all users, on Linux
it is installed in /opt and the executable is linked to /usr/bin the
librexx.so to /usr/lib). So the interpreter lives independently of OOo,
but every process can access it given the above environment setup.
HTH,
---rony
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extension Manager [was: Re: [dev] Seeking help on Ubuntu 6.10 OOo v. 2.0.4 for starting OOo via Java]
Hi there, Hm, if the error message tells the truth, there is some problem accessing that log.txt file. I assume you are on Linux; you could try strace -f ./unopkg gui O.K. it is 1,8 MB large, so I would not like to attach it to this e-mail. I can zip-it up and send it to you via direct e-mail, otherwise please advise. and grep for log.txt on stderr to see if there are indeed any problems. (If a non-gui ./unopkg list does not fail, similar data for strace -f ./unopkg list would also be interesting.) Running ./unopkg list yields the same error it seems, whereas ./unopkg list --shared works. Again, if it helps to create anothe strace for the failing version, please advise. ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extension Manager [was: Re: [dev] Seeking help on Ubuntu 6.10 OOo v. 2.0.4 for starting OOo via Java]
O.K. it is 1,8 MB large, so I would not like to attach it to this e-mail. I can zip-it up and send it to you via direct e-mail, otherwise please advise. Only of interest are lines containing log.txt. Should be few enough to post inline. (Also, does an ls -l on that log.txt file show any anomalies?) Ad ls -l log.txt: just noticed that the owner and group is root! So here is the entire listing: [EMAIL PROTECTED]:~/.openoffice.org2/user/uno_packages/cache$ ls -al insgesamt 32 drwxr-xr-x 4 rony rony 4096 2007-02-12 13:18 . drwxr-xr-x 3 rony rony 4096 2007-01-20 22:41 .. -rw-r--r-- 1 root root 212 2007-02-04 12:46 log.txt drwxr-xr-x 6 root root 4096 2007-02-03 22:51 registry -rw-r--r-- 1 rony rony 1 2007-02-12 13:18 stamp drwxr-xr-x 2 root root 4096 2007-02-03 22:51 uno_packages -rw-r--r-- 1 root root 12288 2007-02-04 12:46 uno_packages.db [EMAIL PROTECTED]:~/.openoffice.org2/user/uno_packages/cache$ Not sure, how this came into being though. Did a normal install (using alien to turn the rpm packages into deb ones and installing the deb packages).. Changing owner and group to rony (recursively) solved the problem: all variants of unopkg as well as Tools-Extension Manager work now! Regards, ---rony
Re: [dev] Extension Manager [was: Re: [dev] Seeking help on Ubuntu 6.10 OOo v. 2.0.4 for starting OOo via Java]
Hi Roderick, http://www.openoffice.org/issues/show_bug.cgi?id=54163 as mentioned in the Debian section of http://documentation.openoffice.org/setup_guide2/2.x/en/SETUP_GUIDE.pdf ? thank you for the links, and indeed, it seems that this is the same bug (even 18 months later). [Will look into the version of alien that I have used as the docs indicate (so it seems) that the bug should have been removed after v8.50.] Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Little update (Re: [dev] Seeking help on Ubuntu 6.10 OOo v. 2.0.4 for starting OOo via Java
Hi, these were the required jar files suggested by netbeans: (i noticed you didnt mention jut.jar in the comments of your code) juh.jar jurt.jar jut.jar officebean.jar ridl.jar unoil.jar Thank you for this list, will look into it! --- Ad your environment: it seems that you have the OOo SDK (and NetBeans) at your disposal. The successful run from a packaged jar-file is interesting: if possible, could you supply the jar as well your environment settings in the command line window in which you are able to run the app successfully? See, I would like to learn what is needed for an out-of-the-box Ubuntu OOo installation to be employed to run Java apps from the command line. (Here SDK/NetBeans/Eclipse setups can come into ones way as it is then not always clear which environment is in effect under which circumstances.) TIA, ---rony P.S.: Will be a week off (practically without e-mail or WWW access), so I may be able to come back only in a week or so. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Little update (Re: [dev] Seeking help on Ubuntu 6.10 OOo v. 2.0.4 for starting OOo via Java
Hi, these were the required jar files suggested by netbeans: (i noticed you didnt mention jut.jar in the comments of your code) juh.jar jurt.jar jut.jar officebean.jar ridl.jar unoil.jar One last remark: it is likely that your pacakge works because of officebean.jar. But I would not want to be dependent on this jar-file as it mandates the usage of OOo. The solution should be genuine such that only the Java-UNO-interface is necessary (mostly acquiring the OOo components, but since URE has been existing, the solution should be standard), as is the case with the genuine OOo installation from the OOo web site. Or with other words: you should be able to execute the compiled Java class from the commandline by issuing java helloworld. If you can make this work with the Ubuntu OOo installation, then I would be very thankful, if you could share the environment setting of that command line window. Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Little update (Re: [dev] Seeking help on Ubuntu 6.10 OOo v. 2.0.4 for starting OOo via Java
Hi, In fact... officebean.jar is not required for the helloworld appit was suggested by the netbeans wizard, but it will work without it That is very interesting! Could you please either send me the jar-file (or its included manifest file) and the settings of CLASSPATH, PATH and LD_LIBRARY_PATH (from the test machine)? TIA, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Seeking help on Ubuntu 6.10 OOo v. 2.0.4 for starting OOo via Java
Hi Stephan, The Ubuntu layout you described in a previous mail (libs in /usr/lib/openoffice/program, jars in /usr/share/java/openoffice) cannot work (at least not without some modifications to the OOo code base). Not sure why Ubuntu decided to ship a broken OOo (maybe they are not even aware of it, maybe you can file them an issue). Well, ashok seems to be able to deploy the Java program, if it is embedded in a jar-file, it seems. So not sure yet, why it works there and not here. Will have to look further into this. [However, the Extension manager on the tools menu does not work either in this version; it does from the commandline, though, ie. unopkg works there.] What is broken with the extension manager? It does not come up (nor in the genuine OOo installation). I have Sun's Java installed and activated. Will look into this once more to make sure that my scripts did not alter the standard installation. Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Little update (Re: [dev] Seeking help on Ubuntu 6.10 OOo v. 2.0.4 for starting OOo via Java
Hi Jürgen, the problem is quite simple. The Ubuntu guys install OpenOffice or part of it in a way which is not supported in all cases. For example the Java UNO bootstrap mechanism depends on a specific layout (directory structure, Stephan has pointed out earlier). And yes i agree that they probably don't test it at all. For some distributions (we had this problem before with Debian as well) it is enough when OO.org started and the UI appears correctly. You should submit an issue to Ubuntu and communicate the problem there. O.K., will have a week's time (off-line) to look into this further to be sure that it is really them. It seems however that ashok_ somehow is able to run the test program from a jar (but am not sure why and how yet). Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Next .... (Re: [dev] Little update (Re: [dev] Seeking help on Ubuntu 6.10 OOo v. 2.0.4 for starting OOo via Java
Hi there, thanks to everyone, I was not aware of special needs to find OOo. Ashok was kind enough to send me his jar file, and its content is: Archive: helloworld.jar testing: META-INF/OK testing: META-INF/MANIFEST.MF OK testing: org/ OK testing: org/openoffice/ OK testing: org/openoffice/helloworld/ OK testing: org/openoffice/helloworld/helloworld.class OK testing: com/ OK testing: com/sun/ OK testing: com/sun/star/OK testing: com/sun/star/lib/OK testing: com/sun/star/lib/loader/ OK testing: com/sun/star/lib/loader/InstallationFinder$StreamGobbler.class OK testing: com/sun/star/lib/loader/InstallationFinder.class OK testing: com/sun/star/lib/loader/Loader$CustomURLClassLoader.class OK testing: com/sun/star/lib/loader/Loader.class OK testing: com/sun/star/lib/loader/WinRegKey.class OK testing: com/sun/star/lib/loader/WinRegKeyException.class OK testing: win/ OK testing: win/unowinreg.dllOK No errors detected in compressed data of helloworld.jar. This matches Jürgen's explanations. However, *where* would one find the com.sun.star.lib.loader. package? (Just did a grep over OOHome/program/classes, but none of those deployed jar would contain a class by that name.) Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] SDK-only Java libs? (Re: [dev] Next .... (Re: [dev] Little update (Re: [dev] Seeking help on Ubuntu 6.10 OOo v. 2.0.4 for starting OOo via Java
Hi Jim, However, *where* would one find the com.sun.star.lib.loader. package? Look in the SDK/classes directory... Get the SDK at api.openoffice.org Oh, I see. Was not aware of that at all. But this would mean that one cannot reliably deploy Java applications from the command line without that supporting library? If so, why not supply it with the general installation of OOo (putting that library into OOoXYZ/classes directory? It seems to me that that would be the appropriate place, which everyone then could rely to find it. Or with other words, distribute that jar as you distribute the juh.jar etc. --- And being there, why not fold juh.jar, etc. into *one* jar only? Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SDK-only Java libs? (Re: [dev] Next .... (Re: [dev] Little update (Re: [dev] Seeking help on Ubuntu 6.10 OOo v. 2.0.4 for starting OOo via Java
Hi there, just a stupid question: why doesn't the Bootstrap helper class use the com.sun.star.lib.loader. knowing the important role of that library to find the OO executable ? Regards, ---rony However, *where* would one find the com.sun.star.lib.loader. package? Look in the SDK/classes directory... Get the SDK at api.openoffice.org Oh, I see. Was not aware of that at all. But this would mean that one cannot reliably deploy Java applications from the command line without that supporting library? If so, why not supply it with the general installation of OOo (putting that library into OOoXYZ/classes directory? It seems to me that that would be the appropriate place, which everyone then could rely to find it. Or with other words, distribute that jar as you distribute the juh.jar etc. --- And being there, why not fold juh.jar, etc. into *one* jar only? Regards, ---rony
Re: [dev] Seeking help on Ubuntu 6.10 OOo v. 2.0.4 for starting OOo via Java
Hi Caio Tiago, thank you *very* much, your directions worked right out of the book! ;) First I deinstalled the Ubuntu OOo, then followed your instructions and was able to install the genuine OOo from the OOo homepage, getting the standard installation tree on the /opt branch. Could get the Java program to run from the command line, ie. bootstrapping OOo worked! [However, the Extension manager on the tools menu does not work either in this version; it does from the commandline, though, ie. unopkg works there.] Again, thank you *very* much for your kind and exact help! ---rony P.S.: Will take another look into the OOo installation as coming from Ubuntu (also Suse, I found out). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Seeking help on Ubuntu 6.10 OOo v. 2.0.4 for starting OOo via Java
Hi Jim, You should get the Software Development Kit from your distribution or from http://api.openoffice.org, there are examples in SDK/examples/DevelopersGuide/FirstSteps This assumes, that the Java program I use would not work. However, it is a simple test-program which has been working like a charm, and which I have been using to make sure that the environment for Java is set up correctly, such that I am assured that problems in developing apps do not stem from a wrong environment. --- Caio Tiago Oliveria hit the nail right on the top and I could successfully get and install the genuine OOo from the OOo homepage (kudos to him) ! Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Little update (Re: [dev] Seeking help on Ubuntu 6.10 OOo v. 2.0.4 for starting OOo via Java
Hi there, just wanted to report that the genuine OOo 2.1 can be invoked via Java from the command line, whereas the Ubuntu version cannot. Did remove the genuine OOo 2.1 and re-installed the Ubuntu OOo 2.0.4 version (the latest they have). The Ubuntu version places the binaries into /usr/lib/openoffice/program and the Java support to /usr/share/java/openoffice. Setting CLASSPATH and LD_LIBRARY_PATH+PATH to their respective settings does throw a com.sun.star.comp.helper.BootstrapException (bootstrap cannot find office executable). Could it be that they have no test case for running OOo from the commandline using Java ? Could that really be the case?? Or is there something that I might still oversee, which is important for the Ubuntu version but not for the genuine OOo distribution? Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Little update (Re: [dev] Seeking help on Ubuntu 6.10 OOo v. 2.0.4 for starting OOo via Java
Hi, ashok _ wrote: I am running oOo 2.1 on ubuntu... I am running the standard jdk 1.5.08 installation... everything works fine for me. I noticed that i had to explicitly enable Java in oOo after the installation, by going to tools-options-java and expicitly selecting a JVM there maybe that is the step you are missing? This seems to be necessary only, if Java is invoked from OpenOffice itself (either via the scripting framework, or because of using a Java UNO component, etc.). If one is using Java from the outside of OOo then that version of Java is used to drive OOo. One could set up different vesions of Java and use them to interface with OOo (as a matter of fact I have Java 1.1, 1.2, 1.3, 1.4, 1.5 and 1.6 on my machine, using 1.4 through 1.6 when running against OOo). --- So the question would be for me whether you are able to compile and run the enclosed Java program from the *command* line (not NetBeans, Eclipse etc.) under Ubuntu's OOo? If so, I would be *very* interested in your environment settings! TIA, ---rony CreateTextDocument.java Description: java/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] A few brief questions ad extension packages (Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Hi Stephan, Feel free to come back here with any questions along your way, Thank you very much for your kind offer! Indeed, after studying your information there would be a couple of questions: * where would one find the full definition for manifest.xml and a list of valid mainfest:media-types; I looked in the developers guide and tried the search function of the Wiki, but have not been really able to locate it? * also, where would one be able to find the full definition for the description.xml file? o ad version numbers: would something like 2.1.0.20070202 or 210.20070202 be o.k. (according to the production rule it should be possible) or would that pose any problems (the date of the version is the trailing value, possibly supplemented with the time of the day like 210.20070202162200) * ad application/vnd.sun.star.uno-component;type=native: o This can be used to not only denote libraries, but also executables and modules (or with other words: these files will be put into a place that is accessible via the PATH settings?) o Is there a complete list somewhere of the operating system dependent strings? The extension document mentions Windows, Linux_x86, Solaris_SPARC. So what about PPC versions of Linux or Intel versions of Solaris or PPC and/or Intel versions of MacOSX? * is there a possibility to copy a set of scripts (in any available scripting language) to the user and/or shared script repository? If possible, what would be the appropriate manifest:media-type entry? o Of course this may pose a little problem when using the update feature, as such scripts could have been edited in the meantime by the users (but then one could resolve this by moving the existing/edited extension scripts to an own backup library) TIA, ---rony
Re: [dev] A few brief questions ad extension packages (Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Hi Stephan, thank you very much for your answers! ... cut ... * ad application/vnd.sun.star.uno-component;type=native: No, such files are not put on any path. If those libraries are UNO libraries that support services/singletons, they will be found by the UNO framework via the information recorded at deployment time. If those libraries are used by other libraries, those libraries must make sure to find them (e.g., via RPATH on ELF platforms). Hmm, in the case of the ooRexx scripting engine: * there is a platform dependent DLL/so which needs to be accessible (at the moment I copy it into OOoHome/program), so the library is *not* an UNO-component, just a native library, * there are three text files (actually ooRexx programs) named BSF.CLS, UNO.CLS, UNO_XINTERFACES.REX which also need to be accessible by ooRexx scripts (and for that reason I have to copy them into OOoHome/program. Is there a means with the extension package manager (via a manifest:media-type) to cause these files to be either made accessible via [D]PATH/LD_LIBRARY_PATH and PATH, or have a means available to tell the package manager where to copy these files in the standard OOo installation tree in a platform independent manner)? Regards, ---rony
[dev] Roundup extension packages for scripting engines ... (Re: [dev] A few brief questions ad extension packages (Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respectiv
Hi Stephan, after further experimentations a synopsis: * In order to install a scripting package under OOo one needs to supply a jar-file according to the scripting framework specs o if all parts are Java then adding all needed classes to that jar-file should be sufficient * Fo a scripting language that is not implemented in Java in addition to the Java plug-in code one needs (example is ooRexx) to deploy o native (non-UNO) libraries (on [D]PATH, LD_LIBRARY_PATH), o a JRE to bridge Java and the non-Java scripting language (on CLASSPATH), o native (non-UNO) binaries resp. text-files that are script modules which need to be accessible as if they were placed along the PATH. At the moment this is not possible. Also the OOo scripting framework needs a MANIFEST.MF in a predefined form. Finally, being able to package and deploy scripts in any scripting language that can be used for OOo would be important as well. Regards, ---rony
Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Hi Stephan, thank you *very* much for your hints and pointers, which I need to follow and study in full in order to be able to experiment with it! (Will take some time, though.) If the three additional jars (bsf-v242-20070128.jar, bsf-rexx-engine.jar, oorexx-uno.jar) are only needed by ScriptProviderForooRexx.jar, create a ScriptProviderForooRexx.oxt extension (see http://api.openoffice.org/files/documents/22/3887/Extensions.pdf) instead that contains all four jars (and can also contain additional information like extension identifier, version, update information, see http://wiki.services.openoffice.org/wiki/Extensions_packaging). That way, your functionality (a script provider for ooRexx) comes as a self-contained entity (that can be deployed in one step via unopkg or OOo's Tools - Extension Manager...), without the need to add additional jars to special places (OOo's program/classes, JVM's extension path). That sounds exactly what I have been looking for (in addition I will have to supply platform dependent DLLs/so platforms and supportive - platform independent - scripts), could glimpse over it already a bit and saw that link libraries can be bundled for different platforms. Also it seems, that deploying the extension will become really easy for the user, including updating the extension! Again, thank you very much! Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Bonsoir Cedric, Stephan Bergmann a écrit : That way, your functionality (a script provider for ooRexx) comes as a self-contained entity (that can be deployed in one step via unopkg or OOo's Tools - Extension Manager...), without the need to add additional jars to special places (OOo's program/classes, JVM's extension path). This is already implemented in the Eclipse integration: the generated package will include the libraries contained in your project and added to the project classpath. Thus you don't have to know how to do it, simply use File Export Menu ;) I'll be pleased to answer questions on that topic if needed. Thank you very much for your kind offer! Will definitely look into this Eclipse plugin (and congratulations for having it now in the Eclipse Central Plugin repository)! Though it will take some time, as I would like to study the needed setup for extension packages by hand and experiment with it (in order to really understand the framework and its ramifications). Once that is in place, I really would like to get to learn and to know your Eclipse plugin and what it can do to help free up development and maintenance time! :) Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Ruby binding
Hi Andrzej, Juergen Schmidt wrote: i would also go forward with JRuby first, based on top of the scripting framework and the Java UNO binding. One thing you have to do is to provide an appropriate script provider. That's already done - thanks to Mr. Rony Flatscher I only did some minor edits to his script provider for ooRexx, and JRuby scripts are already being called in OO. However there's of course some work left with JRuby-UNO integration, because bare Ruby is not so convenient as it should be in OO. I'll be working on it now. *Great* news ! Looking forward to your first scripts once you finished your preliminary JRuby-UNO integration! Regards, ---rony P.S.: Once I get the ooRexx scripting language support packaged into an extension package, I will send you the respective information, such that you can do the same for JRuby, if you want. Still some studying (and testing!) ahead, so it'll take some time. If it works the way as with the other extension packages, this will be very attractive, as it allows a very easy install for the user.
[dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Hi there, for finalizing a package for bridging ooRexx with OOo (UNO) I was able to create a package that can be deployed successfully with unopkg add --shared ScriptProviderForooRexx.jar The scripting language is registered and shows up in the Macro menu. In order to ease installation and maintenance, I added the Class-Path: entry to the manifest files, denoting the jars needed to run. These jar-files were copied to OOoHome/program/classes (one DLL needed for Java and ooRexx, as well as supporting ooRexx scripts to OOoHome/program. This is the manifest file (and the package registers successfully): Manifest-Version: 1.0 RegistrationClassName: com.sun.star.script.framework.provider.oorexx.S criptProviderForooRexx Class-Path: bsf-v242-20070128.jar bsf-rexx-engine.jar oorexx-uno.jar Created-By: ... Built-By: ... Name: org/oorexx/uno Specification-Title: ooRexx to/from UNO Bridge Specification-Version: 0.99 Specification-Vendor: ... Implementation-Title: org.oorexx.uno-via-bsf4rexx Implementation-Version: 0.99 Implementation-Vendor: ... Maybe it is something simple/stupid I am overseeing. Other than that I could create a mega-package adding the content of the other jars into this Scripting framework one. Yet another solution (which I have employed quite successfully) is to install the infrastructure-jars (which may be usabel in other Java applications) as a Java extension. Thankful again for any hints... ---rony
Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?
Hi there, just a small update to my little (still open!) question: copying the jar-files listed on Class-Path to the same directory the OOo package installer chose to install the jar file containing that Class-Path entry will allow to find those jar files. Now, if I knew upfront where the OOo package installer will put the jar, I could copy the other jars to that directory. But looking at the directory on Windows: D:\Programme\OpenOffice.org 2.1\share\uno_packages\cache\uno_packages\24.tmp_ looks as if that name could not be foreseen (24.tmp_ looks like an arbitrary name). Now, how about the relative depth of that directory (on both, Windows and Linux), would it be always on that level? If so, then I could reformulate the Class-Path-entry to read: Class-Path: ../../../../../program/classes/bsf-v242-20070128.jar ../.. /../../../program/classes/bsf-rexx-engine.jar ../../../../../program/ classes/oorexx-uno.jar Not looking nice, but serving its purpose (it works). But again: would the depth of the cached package directory remain and be the same on Linux? Or do you think that packaging everything into one jar-file would be best? Regards, ---rony Rony G. Flatscher wrote: Hi there, for finalizing a package for bridging ooRexx with OOo (UNO) I was able to create a package that can be deployed successfully with unopkg add --shared ScriptProviderForooRexx.jar The scripting language is registered and shows up in the Macro menu. In order to ease installation and maintenance, I added the Class-Path: entry to the manifest files, denoting the jars needed to run. These jar-files were copied to OOoHome/program/classes (one DLL needed for Java and ooRexx, as well as supporting ooRexx scripts to OOoHome/program. This is the manifest file (and the package registers successfully): Manifest-Version: 1.0 RegistrationClassName: com.sun.star.script.framework.provider.oorexx.S criptProviderForooRexx Class-Path: bsf-v242-20070128.jar bsf-rexx-engine.jar oorexx-uno.jar Created-By: ... Built-By: ... Name: org/oorexx/uno Specification-Title: ooRexx to/from UNO Bridge Specification-Version: 0.99 Specification-Vendor: ... Implementation-Title: org.oorexx.uno-via-bsf4rexx Implementation-Version: 0.99 Implementation-Vendor: ... Maybe it is something simple/stupid I am overseeing. Other than that I could create a mega-package adding the content of the other jars into this Scripting framework one. Yet another solution (which I have employed quite successfully) is to install the infrastructure-jars (which may be usabel in other Java applications) as a Java extension. Thankful again for any hints... ---rony
Re: [dev] Ruby binding
Hi Andrzej, Stephan Bergmann wrote: Andrzej Zawadzki wrote: is there any kind of work going on with Ruby binding to UNO? None that I am aware of, at least. Go ahead. :) If jruby is an option for the interpreter you could make your life rather easy by taking advantage of Apache BSF (cf. http://jakarta.apache.org/bsf), which allows deploying scripting languages via Java easily. As the OOo scripting framework is written in Java you could use that and make jruby available for it. As I have been successfully employing ooRexx via that infrastructure (and the gamma version is humming along very nicely) I could point you to the respective Java programs which you would have to adapt for it. Not a terrible big job, as you could take over 98% 1:1. If not, were there any attempts on completing such a task? I'm a Ruby/C++ programmer and I'd surely like such a binding done in OO. Since I'll have some free time in the next few months I'm wondering whether I could help in such a project. Again, if JRuby is an option and you are interested in making it available rather quickly, then drop me a note. Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Integration of the OpenOffice.org page into the Firefox browser
Hi Kay, I have created an extension for the Firefox browser. It adds a new main menu with a list of OpenOffice.org related URLs and it adds a search context menu to the IssuesZilla and OO.o search engine. It is an easy way to access the OpenOffice.org web page Please find more on the Wiki page, there you could download the extension : http://wiki.services.openoffice.org/wiki/Firefox_OpenOffice.org_extension Looks very interesting! Just tried to install the downloaded xpi-file on Windows XP, but Firefox reports a problem with the hash (assumes an error in downloading). Did repeat the download and attempt to install to no avail. Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Integration of the OpenOffice.org page into the Firefox browser
Hi Jim, I have created an extension for the Firefox browser. It adds a new main menu with a list of OpenOffice.org related URLs and it adds a search context menu to the IssuesZilla and OO.o search engine. It is an easy way to access the OpenOffice.org web page Please find more on the Wiki page, there you could download the extension : http://wiki.services.openoffice.org/wiki/Firefox_OpenOffice.org_extension Looks very interesting! Just tried to install the downloaded xpi-file on Windows XP, but Firefox reports a problem with the hash (assumes an error in downloading). Did repeat the download and attempt to install to no avail. I just tried here on iMac (intel) and it worked fine, thank you for this feedback/hint! It made me think that something was wrong with my running instance of Firefox. So I shut it down (but had to kill the process eventually) and restarted it and tried to install the Firefox extension, which lo and behold has worked for me now as well ! Regards, ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OpenOffice without Java
Chris Harrington wrote I have some questions regarding the use of Java in OOo. 1. Would there be any OOo performance gains by disabling Java in the build process? AFAICT no. The Java interfaces seem to be created upon demand (the very first time with a noticeable delay, after that not noticable at all). 2. If java was disabled in the build what besides the Base application and some Wizards would be affected? Definitely, do not do that unless you *must* ! In todays world you truly would be *crippling* OpenOffice by such an action! E.g. the scripting framework is written in Java, removing Java means that you cannot use scripting languages like JavaScript, BeanShell or ooRexx for OpenOffice anymore! [Also, for some applications using Java the Java reflection is very important. So if there are OpenOffice distributions not offering that important feature, definitely a certain class of Java applications could not be deployed.] 3. In order to build OOo without Java are there any other flags that need to be passed besides the --disable Java? Sorry, have truly no idea... :) ---rony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Document-URL file:///
Mathias Bauer wrote: Andreas Höhmann wrote: Hello, can OOo load/save documents from Urls like this: https://xyz/getFile?id=111; https://xyz/setFile?id=111; Where can i find the valid protocols for document-urls? OOo does not have built-in support for https. If you are using Gnome you can use the Gnome-VFS instead. On Windows you can use the Web Folders of the OS though this is a little bit awkward (IMHO). Also, you might want to consider to try to use Java (practically every PC has a JRE installed), which would probably make it even more portable. ---rony
Re: [dev] Greek fonts on Linux OO.o
Caolan McNamara wrote: On Mon, 2006-03-13 at 00:35 +0200, Seeker wrote: From a quick search i didn't find the issue. I refer to the problem with greek fonts. When the user types something in Greek OO.o frequently takes the characters from a font which doesn't have the suitable characters with very very very ugly results. You can see the problem here: http://static.flickr.com/25/62583834_0436c1bfff_o.png Note how different 1 and 2 are. The first misses characters and even the ones which appear are very ugly. The ugly fonts appear even in OO.o's GUI. Does installing DejaVu fonts make any difference for you ? http://dejavu.sourceforge.net/ There aren't a lot of good greek-coverage (as opposed to fonts which include some greek characters for math-coverage purposes) But DejaVu apparently has some good coverage there. How about the Gentium font then at: http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiid=gentium Regards, ---rony
