Re: [dev] heads up on cairo 1.4.8 and crashes
On Fri, 2007-06-15 at 12:19 +0100, Caolan McNamara wrote: > FWYi, it *seems* that OOo's gtk theming and cairo 1.4.8 don't play well > together causing: > > X-Error: RenderBadPicture (invalid Picture parameter) > Major opcode: 154 > Minor opcode: 7 > Resource ID: 0x3800597 > Serial No:9507 (9507) > > so if there are mysterious crashes/immediate exits on e.g. right clicking > twice in OOo, > then the cairo version may be relevant. cairo 1.4.4 in comparison is fine. FYI cairo 1.4.10 has been released to fix this. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] To OOo Builders ...
Hi Stephan, Stephan Bergmann wrote: Undecided. For example, echoing of compiler command lines could be helpful when a CWS owner tries to track down why a tinderbox built broke, to see whether it is an issue of the tinderbox build environment or an issue of the CWS... It actually should be easy, to "echo" the command line, which lead to an error in case of an error ... -Stephan Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] To OOo Builders ...
Caolan, Caolan McNamara wrote: FWIW, I build with build build-flags -- other-dmake-flags -s I am going to try that ... where the -s suppresses a goodly part of the output. Actually I think, the output should per default look like: compiling module/source/bla.cxx compiling module/source/foo.cxx linking module/unxlngi6.pro/lib/libgr.so C. Regards Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] To OOo Builders ...
Actually I think, the output should per default look like: compiling module/source/bla.cxx compiling module/source/foo.cxx linking module/unxlngi6.pro/lib/libgr.so Looks good. I'd like to see an option to do build this way at least. But sometimes both methods are good. I upload full build logs along my builds and they were used a lot of times in the past... -- Pavel Janík - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Netbeans (with Openoffice Plugin ) does not start a new client application
Hi Werner, from where do you get the office installation? I remember that we have had problems with distro builds of OpenOffice where the bootstrap mechanism doesn't work because of some magic system integration stuff of the distros. But i thought that these problems was solved at least for Debian ... Mmh, you can try to create a link /usr/bin/soffice -> /opt/openoffice.org2.0.4/program/soffice (or something else matching your installation) and try it again. Please let us know if it works then or not. This is not really satisfying but we can't prevent it and of course it limits the attraction of the simple bootstrap mechanism. It doesn't work reliable. Juergen Werner Schulte wrote: Hi all. I want to use the Netbeans OO plugin to start learning writing Java Extensions for OO. I have the - Netbeans 5.5.1 IDE - OO 2.0.4 - OO 2.0.4 SDK all running on Debian Linux (4.0). I am able to create a new OO client application using the wizard, but Netbeans does NOT start the application. Instead I get the error message com.sun.star.comp.helper.BootstrapException: no office executable found! at com.sun.star.comp.helper.Bootstrap.bootstrap(Bootstrap.java) at org.openoffice.OfficeUNOClientApp.main(OfficeUNOClientApp.java:29) . When I start the Test Application from the console (out of the jar), it the XComponentContext is found. Any help would be appreciated ! Thanks Werner - 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]
[dev] [gsl-dev] header moving in vcl
Hi, to clean up the mess left by CWS headaburemove I will move all headers left in vcl/inc to vcl/inc/vcl. This can be safely ignored by everybody who does not change vcl code or at least not one of the headers involved. Those who do the latter in their CWS please take care that when resyncing to a master which will contain the CWS mergesvp (in which i plan to do this move), the changes done will have to be joined on the new files. Kind regards, pl -- If you give someone a program, you will frustrate them for a day; if you teach them how to program, you will frustrate them for a lifetime. -- Author unknown - 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] [gsl-dev] header moving in vcl
Philipp Lohmann wrote: Hi, to clean up the mess left by CWS headaburemove I will move all headers left in vcl/inc to vcl/inc/vcl. This can be safely ignored by everybody who does not change vcl code or at least not one of the headers involved. Those who do the latter in their CWS please take care that when resyncing to a master which will contain the CWS mergesvp (in which i plan to do this move), the changes done will have to be joined on the new files. Would it not help to separate the exported headers (i.e., the current content of vcl/inc/vcl) from the module-private ones (i.e., the ones now left in vcl/inc)? Just a thought, -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] generated component_getDescriptionFunc removed
hi! in SRC680_m218 adding a fallback function to each shared library, just stating that there is no description, was removed. also generating component_getDescriptionFunc from a description.xml file was removed too as it was unused for years. tschau... ause - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] To OOo Builders ...
Pavel Janík wrote: >> Actually I think, the output should per default look like: >> >> compiling module/source/bla.cxx >> compiling module/source/foo.cxx >> linking module/unxlngi6.pro/lib/libgr.so > > Looks good. I'd like to see an option to do build this way at least. But > sometimes both methods are good. Well disabling the recipe has to be done in the makefiles, i.e. place an '@' sign at the beginning. To get back the full, verbose output pass '-vr' to dmake. (Use `build -- -vr`) > I upload full build logs along my builds and they were used a lot of > times in the past... Indeed, if everything works smoothly the long logfile is anoying, but if something fails it's nice to have it already. Volker -- = http://wiki.services.openoffice.org/wiki/Debug_Build_Problems = PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D signature.asc Description: OpenPGP digital signature
