[dev] OOo-3.0-RC1 fails on Intrepid Ibex?
Hi, I followed the instructions for installing the version 3 software here: http://wiki.services.openoffice.org/wiki/Run_OOo_versions_parallel I can start the soffice application fine, but when I try to run either writer, impress or calc they crash as soon as you try to actually create a document with the following error: terminate called after throwing an instance of 'com::sun::star::uno::RuntimeException' Not terribly helpful I know, but any ideas? My computer is running Ubuntu Intrepid Ibex Alpha 5, I have installed the Java6 JDK via synaptic and I downloaded the OOo 3rc build which does not contain the Java runtime. I have also tried installing the OOo debs properly, i.e. dpkg -i *.deb. The applications installed, but the crash was exactly the same. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] "Howto" get the actual interface type of an UNO service object (via Java) ?
On 09/09/08 19:24, Rony G. Flatscher wrote: 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? 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;". 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. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
Re: [dev] charter discussion ?
sorry, for stepping in that lately. by looking at the current charter there are mainly two areas of work described for the Community Council: * legislative tasks like representation of the community, coordination with various entities, voting, doing proposals * judiciary tasks like arbitrate between different parties inside and outside the community. IHMO one big part is missing, the executive part and if I review the work of the CC this is the main issue within the CC: Doing the actual work, e.g. doing the new elections, make a proposal for something (budget, year plan, policies, etc.) is not making that progress we would like to see. The voluntary approach that the members of the CC are also doing the actual work does simply not work. Typically the current CC members have a lot of other jobs/work so I think most of them are already looking for what they can do less instead of taking over more responsibilities and work. I would propose to delegate the actual work to "officers" which are preparing proposal and let the CC make the final decisions. In that way we can establish subject matter experts which are willing and able to do the actual work and make the CC at the same time more effective. What I can think of that we establish at least following officers: * Exec Officer: preparing meetings, minutes, elections and other administrative stuff * a Secretary: minutes, invitations, etc. * Treasurer * Conference planning officer: planning and coordinating various conferences * Infrastructure Officer: * Engineering/Development Officer: * Localization and Internationalization Officer: * Legal Officer: legal issues, e.g. trademark policies etc. * public relations officer: other Offices (ODF, can be added as needed These Officers can be elected out of the community based on the principles of meritocracy. Officers then would have the right to speak in the CC. The Officers also would be the owner of the according budget.Officers can build working groups. I know that this does not address the concerns regarding the discussion who's electable for the council but I also think that this is not the main point to get the CC to get the work done. From my experience from the last years in the CC I just can say that I'm not able to follow _and_ to work on all the stuff we had on the agenda, what I would like to do is either to judge and vote about well prepared proposals or to work in just one area for the CC. And having the proposals is the harder work to do. But sceptic as I am, I don't think that we'll find people for the all above proposed Offices. And I just don't think that the proposed changes alone in the charter for making more people electable for the CC makes the work in CC better. Martin Michael Meeks wrote: Hi Martin, I notice, at: http://wiki.services.openoffice.org/wiki/Community_Council_Minutes#Minutes there is a section: [snip] "Work on modification of the CC charter The draft for the proposal is now on the wiki. Martin will bring the discussion on the charter to the dev@ list in order to get more feedback from developers (core and non core developers) about the interest of that group to get involved in issues not related to source code. AI: Martin to bring the discussion on dev@ [snip] The draft proposal is here: http://wiki.services.openoffice.org/wiki/Community_Council/Items/Charter_Proposal is there already a thread discussing this ? Thanks, Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] DEV300_m29: compiling ERROR: File not found: ScriptFramework.jar
Hi Nguyen, On Thursday, 2008-09-04 12:17:58 +0900, Nguyen Vu Hung wrote: > >> unxlngi6 folder is 6GB big and it takes a long time. > > > > It should't be that big. All unxlngi* folders together shouldn't be that > > big. > > You really shouldn't try a debug build at first attempt... > I didn't try to debug. Well, for DEV300_m29 my */unxlngi6 folders (without solver) total up to 3.7G, that's with --disable-binfilter and several other --disable-... and --without-..., but with --enable-dbgutil. So 6GB may not be totally off the road, especially if you included binfilter and built mozilla and maybe others from source. You may save some diskspace by delivering hard links to the solver, add option --dlv_switch -link to the build command, which needs using cd $SRC_ROOT/instsetoo_native build --all --dlv_switch -link instead of calling dmake in $SRC_ROOT though. The root makefile.mk is just a wrapper around that. > My question, for dmake, is what is equivalent to GNU make clean > for a *fresh* build? cd $SRC_ROOT dmake clean (surprise ;-) There's also dmake distclean that additionally clears config.cache > I've specified --with-lang=en vi ja but it turned out that only en_Us > is built. Why? > How to enable vi and ja? Looks like you omitted quotes: --with-lang="en-US vi ja" Note also that it is not en but en-US, as opposed to en-GB. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED] Thanks. pgpfcUpG278r0.pgp Description: PGP signature
Re: [dev] charter discussion ?
Hello Martin, What you are saying makes sense. You should perhaps add it to the Talk section of the Charter draft: http://wiki.services.openoffice.org/wiki/Talk:Community_Council/Items/Charter_Proposal Best, Charles. Le 10 sept. 08 à 13:03, Martin Hollmichel a écrit : sorry, for stepping in that lately. by looking at the current charter there are mainly two areas of work described for the Community Council: * legislative tasks like representation of the community, coordination with various entities, voting, doing proposals * judiciary tasks like arbitrate between different parties inside and outside the community. IHMO one big part is missing, the executive part and if I review the work of the CC this is the main issue within the CC: Doing the actual work, e.g. doing the new elections, make a proposal for something (budget, year plan, policies, etc.) is not making that progress we would like to see. The voluntary approach that the members of the CC are also doing the actual work does simply not work. Typically the current CC members have a lot of other jobs/work so I think most of them are already looking for what they can do less instead of taking over more responsibilities and work. I would propose to delegate the actual work to "officers" which are preparing proposal and let the CC make the final decisions. In that way we can establish subject matter experts which are willing and able to do the actual work and make the CC at the same time more effective. What I can think of that we establish at least following officers: * Exec Officer: preparing meetings, minutes, elections and other administrative stuff * a Secretary: minutes, invitations, etc. * Treasurer * Conference planning officer: planning and coordinating various conferences * Infrastructure Officer: * Engineering/Development Officer: * Localization and Internationalization Officer: * Legal Officer: legal issues, e.g. trademark policies etc. * public relations officer: other Offices (ODF, can be added as needed These Officers can be elected out of the community based on the principles of meritocracy. Officers then would have the right to speak in the CC. The Officers also would be the owner of the according budget.Officers can build working groups. I know that this does not address the concerns regarding the discussion who's electable for the council but I also think that this is not the main point to get the CC to get the work done. From my experience from the last years in the CC I just can say that I'm not able to follow _and_ to work on all the stuff we had on the agenda, what I would like to do is either to judge and vote about well prepared proposals or to work in just one area for the CC. And having the proposals is the harder work to do. But sceptic as I am, I don't think that we'll find people for the all above proposed Offices. And I just don't think that the proposed changes alone in the charter for making more people electable for the CC makes the work in CC better. Martin Michael Meeks wrote: Hi Martin, I notice, at: http://wiki.services.openoffice.org/wiki/Community_Council_Minutes#Minutes there is a section: [snip] "Work on modification of the CC charter The draft for the proposal is now on the wiki. Martin will bring the discussion on the charter to the dev@ list in order to get more feedback from developers (core and non core developers) about the interest of that group to get involved in issues not related to source code. AI: Martin to bring the discussion on dev@ [snip] The draft proposal is here: http://wiki.services.openoffice.org/wiki/Community_Council/Items/Charter_Proposal is there already a thread discussing this ? Thanks, Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo 3 antialias ldraw
Nguyen Vu Hung a écrit : 2008/9/10 Jean-Baptiste Faure <[EMAIL PROTECTED]> Nguyen Vu Hung a écrit : In the second slide, I've imported a png file to it( antialias.test.png) 1. Lines looks smooth in Impress 2. However, lines the exported pdf are not smooth. Please view the .odt file with 100% zoom, view .pdf file with Acrobat reader 5.0 100% zoom or Foxit Reader 2.2. Perhaps it 's not necessary : http://www.openoffice.org/issues/show_bug.cgi?id=28526 28526 refers to anti-aliasing for drawing objects, which I've mentioned in the first slide. In the second slide, the "bug" is that when we export an imported bitmap to a pdf, there is no anti-aliasing. Please take a look at 2nd page in the .pdf file I've send in my first email. Hi, when I export the odp file to pdf format, I obtain a pdf file which looks better than odp slide, both for slides 1 and 2. I use Evince viewer under Ubuntu 8.04. I suggest you to try a newer version of Acrobat Reader. JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo 3 antialias ldraw
2008/9/11 Jean-Baptiste Faure <[EMAIL PROTECTED]>: In the second slide, I've imported a png file to it( antialias.test.png) 1. Lines looks smooth in Impress 2. However, lines the exported pdf are not smooth. Please view the .odt file with 100% zoom, view .pdf file with Acrobat reader 5.0 100% zoom or Foxit Reader 2.2. > when I export the odp file to pdf format, I obtain a pdf file which looks > better than odp slide, both for slides 1 and 2. > I use Evince viewer under Ubuntu 8.04. > I suggest you to try a newer version of Acrobat Reader. So what is the point? I should change my pdf viewer or the combo of Evince under Ubuntu? I am using foxit, not acrobat. If OOo does not support anti aliasing, we still see none smooth lines. It may looks better or worse in this pdf viewer or that pdf viewer, but the real cause of the problem is not fixed. -- Best Regards, Nguyen Hung Vu ( Nguyễn Vũ Hưng ) [EMAIL PROTECTED] , YIM: vuhung16 , Skype: vuhung16dg Life through a viewfinder: http://bighugelabs.com/flickr/[EMAIL PROTECTED]
