[dev] Problems on Using SDK
I have installed 1. OOo_1.9.113_Win32Intel_install.zip and install in E:\OpenOffice.org 1.9.113, 2. OOo_1.1.0_Win32Intel_sdk.zip installed in E:\OpenOffice.org1.1_SDK I have run the configureWindowsNT.bat (without CPP setting since i have no VC installed). When i runs idlc command, it reports a error: Can not find stlport_vc745.dll I find that there is a stlport_vc7145.dll in E:\OpenOffice.org 1.9.113\program directory, and i tried to rename from 7145.dll to 745.dll, the idlc can runs but the soffice.exe report Can not find stlport_vc7145.dll Does this mean the SDK1.1.0 not works for OpenOffice 1.9? and can I using cygwin/gcc to build from source instead using MS VC?
Re: [dev] Problems on Using SDK
Hi, 王在祥 wrote: I have installed 1. OOo_1.9.113_Win32Intel_install.zip and install in E:\OpenOffice.org 1.9.113, 2. OOo_1.1.0_Win32Intel_sdk.zip installed in E:\OpenOffice.org1.1_SDK I have run the configureWindowsNT.bat (without CPP setting since i have no VC installed). When i runs idlc command, it reports a error: Can not find stlport_vc745.dll I find that there is a stlport_vc7145.dll in E:\OpenOffice.org 1.9.113\program directory, and i tried to rename from 7145.dll to 745.dll, the idlc can runs but the soffice.exe report Can not find stlport_vc7145.dll Yes, that's true the idlc from the older SDK needs stlport_vc745.dll which doesn't come with OO.1.9.x. So you have to use a newer SDK build or copy the old library form an older OpenOffice version. Does this mean the SDK1.1.0 not works for OpenOffice 1.9? and can I using cygwin/gcc to build from source instead using MS VC? no Juergen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
See [1] for details. And here comes the missing footnote [1] http://specs.openoffice.org/installation/optional_base_module.odt Ciao Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] corrections on the to-dos page
Hi, I think you all are doing an awesome service to anyone who uses office-related software. And, I'm probably not sending this correction to the right department. I'm e-mailing you to point out an error on your to-dos page (http://development.openoffice.org/todo.html). I have pointed out the mistake in bold red below. Near the top of the page, what reads glad that consider to contribute... should be glad that you have considered contributing Just letting you know. As well, it should read We are waiting to start the review. Not awaiting, as I have pointed out in bold purple. If you really just have the urge to use the word awaiting, it could read We are awaiting the start of the review. It's up to you. Keep up the amazing work! OpenOffice.org To-Do List We are glad that you found the To-Do list for the OpenOffice.org project. Thanks to all who applied with an OpenOffice.org project for the Summer of Code initiative. We are awaiting to start the review. We are glad that consider to contribute with programming to OpenOffice.org. Below you'll find a To-Do list containing mixture of areas in need of your help.
Re: [dev] How to keep users away from Base
Hi Frank, all, Frank Schönheit - Sun Microsystems Germany wrote: Hi Matthias, For instance, it would be a good start to remove Database from the quickstarter pop-up and the File/New dialog. How would I do that? Latest builds have a possibility to remove Base from the installation during setup, just as you can do with the other applications. For now, this basically only implies that the New database entries are removed from various places, including the ones you mentioned. Additionally, the data source browser (F4) is removed, and you cannot open DB files from the File|Open dialog. See [1] for details. As I understand it, not every body will want to use Base (HSQLDB integration) but still want to access their external database (like MySQL/SQLite/etc.) without using Base (the database environment). Am I right in using the same word ? Testing the 'with' and 'without' Base option lead us to 2 reflections: - not activating Base during install process don't let you know that you won't access to any of your external database any more (we have tested it during an event last week and users were pretty confused) - we lack a great fonctionnality (yes again ;) that was in the spirit of 1.x branch : the ability to deal with external database under F4 whatever the module you use. Am I right or do I miss something or will it be possible in the future ? Kind regards Sophie -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.1/51 - Release Date: 18/07/2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hi Sophie, As I understand it, not every body will want to use Base (HSQLDB integration) but still want to access their external database (like MySQL/SQLite/etc.) without using Base (the database environment). Am I right in using the same word ? Ehm, well. Terminology is in fact not clear here. There are at least three things: - Base is the application, that is, at least the UI for editing database documents (no matter whether they connect to external or internal databases) - HSQLDB is the engine used when the user asks Base to create a self-contained database document. - There's quite some database-related functionality in the other applications. See the Future Tasks section in the specification I linked to, to get an idea - it's really more one would expect in the first run :) Whether this particular functionality is part of Base or not is debatable. For the data source browser, we decided it *is*. The problem with the optional Base feature (which closed in on very short notice only) is that it's in no way clear what a user expects if she disables Base in the setup. What should be gone then? The application UI? The integrated engine? The integration into other application? The integration into Writer only, or into Calc only? Caring for *all* potential needs here requires much more fine-grained control during setup than the current Base on/off option. As you can see in the Future tasks capter, we're at least aware of this :). Am I right or do I miss something or will it be possible in the future ? No, you're right, there are different use cases, while the current option addresses only one (namely installations where the users should not be able to create/modify database documents of any kind, but only use the ones provided by other parties, and still should have all application-integration). *Whether* and *When* the other use cases will be addressed is not clear (to me) at the moment. It probably depends on how many users/customers think it's necessary :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SimpleBootstrap_cpp Makefile Issue
Hello, After some more investigation, I found the following. The problem comes from the following call : $(OUT_BIN)/_%$(EXE_EXT) : $(OUT_APP_OBJ)/%.$(OBJ_EXT) The problem is the value of the $(OUT_APP_OBJ) variable. After some test this is what I found. Depending on the value it may or may not compile. The original value does not compile : # Not ok OUT_APP_OBJ = $(OUT_OBJ)/$(APP_NAME) OUT_APP_OBJ = $(OUT_OBJ)$(APP_NAME) But the following do : # OK OUT_APP_OBJ = $(APP_NAME) OUT_APP_OBJ = $(OUT_OBJ) OUT_APP_OBJ = $(OUT_BIN) OUT_APP_OBJ = /$(OUT_OBJ)/ With OUT_OBJ = /opt/OpenOffice.org2.0_SDK/examples/DevelopersGuide/ProfUNO/ CppBinding/build/OpenOffice.org2.0_SDK/LINUXexample.out/obj APP_NAME = SimpleBootstrap_cpp Any Idea of wht may be wrong ? Might be an idea to the make a patch to correct this problem. Cheers, Pierre-Andre -- I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone - Bjarne Stroustrup - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hi Frank, Frank Schönheit - Sun Microsystems Germany wrote: Hi Sophie, As I understand it, not every body will want to use Base (HSQLDB integration) but still want to access their external database (like MySQL/SQLite/etc.) without using Base (the database environment). Am I right in using the same word ? Ehm, well. Terminology is in fact not clear here. Well I agree with you and I feel that clearing it will help users to address what they would like :) There are at least three things: - Base is the application, that is, at least the UI for editing database documents (no matter whether they connect to external or internal databases) - HSQLDB is the engine used when the user asks Base to create a self-contained database document. - There's quite some database-related functionality in the other applications. See the Future Tasks section in the specification I linked to, to get an idea - it's really more one would expect in the first run :) Whether this particular functionality is part of Base or not is debatable. For the data source browser, we decided it *is*. Ok I understand it. The problem with the optional Base feature (which closed in on very short notice only) is that it's in no way clear what a user expects if she disables Base in the setup. What should be gone then? The application UI? The integrated engine? The integration into other application? The integration into Writer only, or into Calc only? Well, from the feedback I had (from only one community I agree) is the fact they have to deal any time with Base (the application) when they have to edit a db or do a mailing, etc. is time consuming. Caring for *all* potential needs here requires much more fine-grained control during setup than the current Base on/off option. As you can see in the Future tasks capter, we're at least aware of this :). yes, I understand how difficult it could be :) Imho, I think that most of the new OOo users will evaluate Base (and it's 3 meanings) as the tool that deals with database, like Writer deals with texts. But previous users currently see it as the tool that deals with the self contained database document and really miss the F4 functionalities. It's quicker to do a mailing without the wizard, it's quicker to edit a dBase file without opening the Base application. Am I right or do I miss something or will it be possible in the future ? No, you're right, there are different use cases, while the current option addresses only one (namely installations where the users should not be able to create/modify database documents of any kind, but only use the ones provided by other parties, and still should have all application-integration). ok *Whether* and *When* the other use cases will be addressed is not clear (to me) at the moment. It probably depends on how many users/customers think it's necessary :) Of course :) ok, so let us bring you a large feedback on this ;) Thanks for your answer Kind regards Sophie -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.1/51 - Release Date: 18/07/2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hello Sophie-who-is-never-happy ;-) The fact that in usual installations, the DSB contains less registered data sources than in OOo 1.x, can be worked around by, well, Tools|Options|Databases (and note that if you create a .odb file, the wizard usually automatically registeres it for you, if you do not explicitly uncheck the respective option). oh yes, I completly miss this new dialog, sorry (I read the specs really to quickly, if fact only read your feature description :( That was mostly what I was speaking about. Is it new since m118 or sooner ? Ehm, no, it's quite old already :). There's an RFE requesting that it can be invoked from the DSB, and your reaction again shows me that it's really a pity we couldn't do this for 2.0 anymore. That was those one that you access bys right clicking on a table. But the dialog under tooloption simplify all the process to register db, it's great :) Only copy with drag and drop from one table to another is not possible (Sophie who is never happy ;) Huh? Sorry, what tables do you want to drag'n'drop in this dialog? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SimpleBootstrap_cpp Makefile Issue
* Jürgen Schmidt [EMAIL PROTECTED] [050720 13:26]: Hi, first of all i can't reproduce your problem, the example works fine for me on Windows, Linux and Solaris. Hum... That's weird. I don't have really a good idea but do you have write access in /opt/? Yes. Well, if it works for you, it must be a problem with my configuration and I won't bother anymore with that example. For the background, I am using GNU Make 3.80 on a Linux box. Pierre-Andre -- I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone - Bjarne Stroustrup - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SimpleBootstrap_cpp Makefile Issue
hi! just a wild guess without actually knowing your makefile: maybe concatination of the two variables leaves a string containing a blank. that would break matching the rule. to check, try ttt: echo $(OUT_APP_OBJ) as the first target in your makefile but after setting this variable. tschau... ause Pierre-Andre Galmes wrote: Hello, After some more investigation, I found the following. The problem comes from the following call : $(OUT_BIN)/_%$(EXE_EXT) : $(OUT_APP_OBJ)/%.$(OBJ_EXT) The problem is the value of the $(OUT_APP_OBJ) variable. After some test this is what I found. Depending on the value it may or may not compile. The original value does not compile : # Not ok OUT_APP_OBJ = $(OUT_OBJ)/$(APP_NAME) OUT_APP_OBJ = $(OUT_OBJ)$(APP_NAME) But the following do : # OK OUT_APP_OBJ = $(APP_NAME) OUT_APP_OBJ = $(OUT_OBJ) OUT_APP_OBJ = $(OUT_BIN) OUT_APP_OBJ = /$(OUT_OBJ)/ With OUT_OBJ = /opt/OpenOffice.org2.0_SDK/examples/DevelopersGuide/ProfUNO/ CppBinding/build/OpenOffice.org2.0_SDK/LINUXexample.out/obj APP_NAME = SimpleBootstrap_cpp Any Idea of wht may be wrong ? Might be an idea to the make a patch to correct this problem. Cheers, Pierre-Andre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Error 65280 occurred while building OOo under WindowsXP SP2
Hello, I am trying to build OpenOffice under Windows platform. I am using, OOo_1.9.113_src.tar.gz and going step by step thru, http://tools.openoffice.org/dev_docs/build_windows_tcsh.html Every thing was going fine, but while I start building using the command in tcsh, cd $SRC_ROOT cd instetoo_native build --all it compiled for an hour then gave some compilation errors. The error message was, = /cygdrive/d/OOo_SRC/sal/systools/win32/kill -- Making: ../../../wntmsci10.pro/misc/kill.dpc dmake subdmake=true -f makefile.mk depend=t ALLDPC Making : Dependencies /usr/bin/touch.exe ../../../wntmsci10.pro/misc/kill.dpc -- Making: ../../../wntmsci10.pro/obj/kill.obj guw.pl /cygdrive/d/INSTAL~1/MICROS~1.NET/Vc7/bin/cl.exe -Zm500 -wd4251 -wd4275 -wd4290 -wd4786 -wd4800 -Zc:forScope -GR -c -nologo -Gs -Gy -I. -I. -I../inc -I../../../inc -I../../../WIN/inc -I../../../wntmsci10.pro/inc -I. -I/cygdrive/d/OOo_SRC/solver/680/wntmsci10.pro/inc/stl -I/cygdrive/d/OOo_SRC/solver/680/wntmsci10.pro/inc/external -I/cygdrive/d/OOo_SRC/solver/680/wntmsci10.pro/inc -I/cygdrive/d/OOo_SRC/solenv/wntmsci10/inc -I/cygdrive/d/OOo_SRC/solenv/inc -I/cygdrive/d/OOo_SRC/res -I/cygdrive/d/OOo_SRC/solver/680/wntmsci10.pro/inc/stl -I/cygdrive/d/INSTAL~1/J2SDK1~1.2_0/include/win32 -I/cygdrive/d/INSTAL~1/J2SDK1~1.2_0/include -I/cygdrive/d/INSTAL~1/MICROS~1/include -I/cygdrive/d/INSTAL~1/MICROS~1.NET/Vc7/include -I/cygdrive/d/Installed/DXSDK/include -I. -I../../../res -I. -Ob1-Zi -Fd../../../wntmsci10.pro/misc/_ooo_st_kill.PDB -Oxs -Oy- -Gd -GX -DWNT -DWNT -DNT351 -DMSC -DM1310 -DINTEL -D_USE_NAMESPACE -D_X86_=1 -DFULL_DESK -DSTLPORT_VERSION=400 -DWINVER=0x400 -D_WIN32_IE=0x400 -D_MT -DCPPU_ENV=msci -DSUPD=680 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DEXCEPTIONS_ON -DCUI -DSOLAR_JAVA -DSRC680 -DMULTITHREAD -DWIN32 -D_MT -DWIN32 -D_MT -W3-Fo../../../wntmsci10.pro/obj/kill.obj /cygdrive/d/OOo_SRC/sal/systools/win32/kill/kill.cxx guw.pl /cygdrive/d/INSTAL~1/MICROS~1.NET/Vc7/bin/cl.exe @/tmp/mkOzLOvz kill.cxx d:\OOo_SRC\sal\systools\win32\kill\kill.cxx(211) : error C3861: 'GetProcessId':identifier not found, even with argument-dependent lookup dmake: Error code 2, while making '../../../wntmsci10.pro/obj/kill.obj' ---* tg_merge.mk *--- ERROR: Error 65280 occurred while making /cygdrive/d/OOo_SRC/sal/systools/win32/kill = My OS is : Windows XP with Service Pack 2 CPU: Intel Pentium 4 I got the following poster had this same issue, but none replied. http://www.openoffice.org/servlets/ReadMsg?list=devmsgId=2026823 Any help? Regards, `Jamil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hallo Frank, For now, this basically only implies that the New database entries are removed from various places, including the ones you mentioned. Additionally, the data source browser (F4) is removed, I've just tested m118 without Base and I like the feature set. I especially like the reduced Base dialog that allows the user to edit existing databases and to use existing queries but does not allow saving to another file, creating new tables or queries etc. From the POV of our policy this seems even more useful than having no Base UI at all, because that way users can still work with existing databases provided by the admin but can not create their own. I also like that the Mail Merge wizard still exists and the Insert/Fields/Other.../Database tab still works. and you cannot open DB files from the File|Open dialog. See [1] for details. Well, in m118 you can open them with File/Open, but there's not filter for odb files, you have to use All Files. If you only want to remove the menu entries, but not the DSB - Hmm. Not sure if this is possible, other people might know more about it. In m118 the DSB can still be invoked programmtically with the code you helped me write recently. So we can provide our own macro and button to open it and it's not really a problem that it's gone. Removing things like the database registration (Tools|Options|Databases) is not possible ATM. That was just an idea. As long as users are more or less prevented from creating their own databases, it doesn't hurt if they have UI to register them. And maybe there's a way to disable the Base GUI completely? None except disabling it in the setup, with exactly the consequences described in [1]. As I've said above, I believe that the reduced Base GUI from m118 is even better than no GUI. Any other ideas how I can make life more difficult for users who want to use the Base GUI? One could manually de-register certain UNO services, so that certain functionality becomes unavailable. How do I do that? This could include at least all services which are necessary for the UI. If the above doesn't fit your needs, this would be the way to go. Well it looks like the way implemented in m118 would be enough to solve my problem, although I will have to discuss this with my superiors before I can be sure. The thing I'm worrying about is how stable the m118 feature set is. Reading [1] gives me the impression that it is not stable, that disabling Base at installation time will remove more functionality in future. And if for instance the Mail Merge Wizard disappears completely or registering databases via UNO stops working, then installing without Base will no longer be an option for us and we'll be in the same fix as we're now, only worse, because by that time we'll probably have established a policy that mandates disabling Base at install time, that would have to be overturned (which is difficult). To make this more clear, it won't be a problem for us if there remains a set of install options to get back the m118 feature set, but if OO.o 2.0 Final ships with only the option to enable or disable Base completely and disabling removes a crucial feature, then we'll be in big trouble if we establish a policy now based on the m118 feature set. Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hi Frank , Frank Schönheit - Sun Microsystems Germany wrote: Hello Sophie-who-is-never-happy ;-) :) The fact that in usual installations, the DSB contains less registered data sources than in OOo 1.x, can be worked around by, well, Tools|Options|Databases (and note that if you create a .odb file, the wizard usually automatically registeres it for you, if you do not explicitly uncheck the respective option). oh yes, I completly miss this new dialog, sorry (I read the specs really to quickly, if fact only read your feature description :( That was mostly what I was speaking about. Is it new since m118 or sooner ? Ehm, no, it's quite old already :). There's an RFE requesting that it can be invoked from the DSB, and your reaction again shows me that it's really a pity we couldn't do this for 2.0 anymore. well, no matter the time if it's going to happen ;) That was those one that you access bys right clicking on a table. But the dialog under tooloption simplify all the process to register db, it's great :) Only copy with drag and drop from one table to another is not possible (Sophie who is never happy ;) Huh? Sorry, what tables do you want to drag'n'drop in this dialog? Not in the new toolsoptionsbase dialog, but we are not able any more to copy a table from one db to another by a simple drag'n drop in the DSB, or is it a bug ? Kind regards Sophie -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.1/51 - Release Date: 18/07/2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hi Matthias, there are some new API features available in 2.0 and one of them would certainly be of great benefit to you: programmatic GUI-control, meaning full control over menu items and toolbars. Recently there were some talks on [EMAIL PROTECTED] about those new things, as you can check when searching through the archives. Currently the api project webpage does not reflect oo 2.0 beta status, thus you need to get the newest sdk available to read yourself through provided documentation on that area, I believe the newest sdk is m113 right now. The ones of interest for you would be css::ui::XUIConfigurationManagerSupplier and related objects, as well as css::frame::XLaoutManager . In principal you could easily disable, hide or delete certain menu entries or toolbar icons, thus giving the user no way to easily open up a new database document for example. And if you don't want to go this way, there is even the chance of registering your own component integrating a DispatchInterceptor which actually can receive every single ui dispatch possible, which would give you even more control about what happens when a user clicks this or that button (dispatch slot ids can be found on http://api.openoffice.org). Let me know if you need some start, I have got some examples of code in Starbasic. 2005/7/20, Matthias Benkmann [EMAIL PROTECTED]: Hallo Frank, For now, this basically only implies that the New database entries are removed from various places, including the ones you mentioned. Additionally, the data source browser (F4) is removed, I've just tested m118 without Base and I like the feature set. I especially like the reduced Base dialog that allows the user to edit existing databases and to use existing queries but does not allow saving to another file, creating new tables or queries etc. From the POV of our policy this seems even more useful than having no Base UI at all, because that way users can still work with existing databases provided by the admin but can not create their own. I also like that the Mail Merge wizard still exists and the Insert/Fields/Other.../Database tab still works. and you cannot open DB files from the File|Open dialog. See [1] for details. Well, in m118 you can open them with File/Open, but there's not filter for odb files, you have to use All Files. If you only want to remove the menu entries, but not the DSB - Hmm. Not sure if this is possible, other people might know more about it. In m118 the DSB can still be invoked programmtically with the code you helped me write recently. So we can provide our own macro and button to open it and it's not really a problem that it's gone. Removing things like the database registration (Tools|Options|Databases) is not possible ATM. That was just an idea. As long as users are more or less prevented from creating their own databases, it doesn't hurt if they have UI to register them. And maybe there's a way to disable the Base GUI completely? None except disabling it in the setup, with exactly the consequences described in [1]. As I've said above, I believe that the reduced Base GUI from m118 is even better than no GUI. Any other ideas how I can make life more difficult for users who want to use the Base GUI? One could manually de-register certain UNO services, so that certain functionality becomes unavailable. How do I do that? This could include at least all services which are necessary for the UI. If the above doesn't fit your needs, this would be the way to go. Well it looks like the way implemented in m118 would be enough to solve my problem, although I will have to discuss this with my superiors before I can be sure. The thing I'm worrying about is how stable the m118 feature set is. Reading [1] gives me the impression that it is not stable, that disabling Base at installation time will remove more functionality in future. And if for instance the Mail Merge Wizard disappears completely or registering databases via UNO stops working, then installing without Base will no longer be an option for us and we'll be in the same fix as we're now, only worse, because by that time we'll probably have established a policy that mandates disabling Base at install time, that would have to be overturned (which is difficult). To make this more clear, it won't be a problem for us if there remains a set of install options to get back the m118 feature set, but if OO.o 2.0 Final ships with only the option to enable or disable Base completely and disabling removes a crucial feature, then we'll be in big trouble if we establish a policy now based on the m118 feature set. Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards Christian Junker
[dev] localize patch for openoffice.org2
Hi rene and ooo maintainer, Here is a patch for openoffice.org2, which fixed some error of localizations. The original source forgets to put a dbl-quotes beside OOO_VENDOR and OOO_LICENSE vars in some language, such as zh-CN and it. Thx. -- Stanley Peng [EMAIL PROTECTED] localize.tar.gz Description: GNU Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
