[dev] --enable-crashdump=STATIC
OOo configure since a long time accepts an --enable-crashdump switch with possible arguments yes|TRUE|STATIC|no. It controls whether the ENABLE_CRASHDUMP environment variable is set to TRUE, STATIC, or (the empty string). However, all the places that read that environment variable (in DEV300_m68: crashrep/source/unx/makefile.mk, sal/osl/unx/makefile.mk, scp2/source/crashrep/makefile.mk, scp2/source/ooo/makefile.mk, scp2/util/makefile.mk, solenv/inc/settings.mk) only check that its value is not empty, but never explicitly check for either TRUE or STATIC. Does anybody remember what --enable-crashdump=STATIC should have been good for? Should it still be relevant? -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] --enable-crashdump=STATIC
On Wed, 2010-01-06 at 10:23 +0100, Stephan Bergmann wrote: Does anybody remember what --enable-crashdump=STATIC should have been good for? Should it still be relevant? Issue 16528, issue 16633. I think the idea was that using STATIC would link the graphical crash reporter statically against gtk, while true/yes would link it dynamically. There isn't a graphical gtk crashreporter anymore right ?, if so then STATIC/TRUE can go away. As can crashrep/interface.* interface/res.cxx etc. seeing as I only see main.obj mentioned in the makefile.mk there. Also presumably the -lXext -lX11 for MacosX is bogus as well etc. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] --enable-crashdump=STATIC
Hi, Le 6 janv. 10 à 10:42, Caolán McNamara a écrit : Also presumably the -lXext -lX11 for MacosX is bogus as well etc. You're right : it was correct in the X11 times. Today, everything X11 is completely obsolete in the sources. Regards, Eric Bachard -- qɔᴉɹə
Re: [dev] --enable-crashdump=STATIC
On 01/06/10 10:42, Caolán McNamara wrote: On Wed, 2010-01-06 at 10:23 +0100, Stephan Bergmann wrote: Does anybody remember what --enable-crashdump=STATIC should have been good for? Should it still be relevant? Issue 16528, issue 16633. I think the idea was that using STATIC would link the graphical crash reporter statically against gtk, while true/yes would link it dynamically. There isn't a graphical gtk crashreporter anymore right ?, if so then STATIC/TRUE can go away. As can crashrep/interface.* interface/res.cxx etc. seeing as I only see main.obj mentioned in the makefile.mk there. Also presumably the -lXext -lX11 for MacosX is bogus as well etc. Thanks; filed http://www.openoffice.org/issues/show_bug.cgi?id=108102. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Stay-put buttons
Is there any way to put an array of masses of buttons on an OOo spreadsheet so that they stay put (in the visible window) while the sheet scrolls? Background: I'm trying to develop a replacement for an app for occasional users which is currently running on Lotus 123 R5 under Win 3.1! On that it's done by splitting the screen right-left, putting the user entry area in the left half and the buttons in the right half and desynching the scroll but OOo doesn't seem to support that (and in any case that was prone to occasional users scrolling things off screen). But that layout is what I'd like to get. I looked at toolbars but a) when you generate the toolbar it just puts in as text whatever name you've given the relevant macro without AFAICS any control over colours or font size and I guess without the ability to indicate keyboard shortcuts. If I dock the generated toolbar on the edge of the window (I don't want to reduce the visible rows - I'd need probably 3 toolbars for all the functions and it's a smallish screen) it rotates the text which is hopeless. Another idea is to open another window with the buttons in it but I'm struggling to access the 2 views independently so that each gets put in it's proper position displaying the right thing. But at best it will look pretty clonky with the extra window frames and the focus flipping between the two; actually t'would be nice if I could full-screen it so users can't move it. There must be a better way? -- Dick Georgeson - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Stay-put buttons
On 01/06/10 12:52, R. Georgeson wrote: I looked at toolbars but a) when you generate the toolbar it just puts in as text whatever name you've given the relevant macro without AFAICS any control over colours or font size and I guess without the ability to indicate keyboard shortcuts. If I dock the generated toolbar on the edge of the window (I don't want to reduce the visible rows - I'd need probably 3 toolbars for all the functions and it's a smallish screen) it rotates the text which is hopeless. An add-on component can also specify images instead of text for its toolbar entries, see http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/WritingUNO/AddOns/Images_for_Toolbars_and_Menus. Maybe that helps. Niklas - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Reg: Shrinking openoffice setup size for document converter
We have checked out the latest openoffice source code in Ubuntu Linux and Windows and successfully created and installed the OpenOffice setup from the source code. We are working on creating a portable openoffice setup based document converter, whose final setup size has to be shrinked to 50MB from the latest openoffice source. A similar setup created by PortableApps for OpenOffice 3.1 is of size 98MB. We are going through the wiki pages, source code and searching the developer mailing archive. Any help or pointers would be greatly appreciated and useful. Thanks in Advance, Aatral
Re: [dev] Reg: Shrinking openoffice setup size for document converter
The first Idea which comes to mind is to disable all unnecessary modules by using configure script. Sincerely yours, Kirill 2010/1/6 Aatral Arasu aatr...@gmail.com We have checked out the latest openoffice source code in Ubuntu Linux and Windows and successfully created and installed the OpenOffice setup from the source code. We are working on creating a portable openoffice setup based document converter, whose final setup size has to be shrinked to 50MB from the latest openoffice source. A similar setup created by PortableApps for OpenOffice 3.1 is of size 98MB. We are going through the wiki pages, source code and searching the developer mailing archive. Any help or pointers would be greatly appreciated and useful. Thanks in Advance, Aatral
[dev] Problems while running in Debug mode with NB
Hello, I am trying to debug a extension in Ubuntu 64 with NB 6.8 and OO SDK latest version. But, I came across this error: debugging UNO extension package ... /opt/openoffice.org3/program/unopkg gui -f /home/fabio/NetBeansProjects/UniOffice/dist/UniOffice.oxt starting the Office with ... user installation: file:///home/fabio/NetBeansProjects/UniOffice/build/soffice_debug debug options: -Xdebug -Xrunjdwp:transport=dt_socket,address=lesbia:39057 /opt/openoffice.org3/program/soffice Picked up JAVA_TOOL_OPTIONS: -Xdebug -Xrunjdwp:transport=dt_socket,address=lesbia:39057 FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197) ERROR: transport error 202: connect failed: Connection refused ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510) JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [../../../src/share/back/debugInit.c:690] JavaVM: JNI_CreateJavaVM called _exit, caught by abort_handler in javavm.cxx [Java framework] sunjavaplugin.soCan not create JavaVirtualMachine, abort handler was called. [Java framework] sunjavaplugin.soCan not create Java Virtual Machine fa...@lesbia:/tmp/UniOffice$ java -version java version 1.6.0_15 Java(TM) SE Runtime Environment (build 1.6.0_15-b03) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02, mixed mode) fa...@lesbia:/tmp/UniOffice$ thanks for any advise, fabio.
