Re: [dev] drop configimport?
Stephan Bergmann wrote: Are there any objections against dropping the configimport tool from OOo 3.0? It seems that its typical uses (if any) can also be achieved with other means (see http://www.openoffice.org/issues/show_bug.cgi?id=87512), so we can lose some weight here. done (dropped) -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Long paths on Windows
Oliver Brinzing wrote: Hi, a short question's regarding path's: Is it generally a good idea to have space's and the version number (for example OOo-dev 3.0, Basis 3.0,...) inside the oo install path's ? spaces: no idea if that is good or bad; when coming up with Basis 3.0 I just followed prior art (OpenOffice.org 2.4) version number: see What shall be the paths where the tree layers are installed, and is it necessary to encode any version numbers in those paths? in http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/Three-Layer_OOo -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Long paths on Windows
Hi, spaces: no idea if that is good or bad; when coming up with Basis 3.0 I just followed prior art (OpenOffice.org 2.4) that's true, but till oo 2.4 one had a chance to install to a path without spaces and version numbering, like c:\programs\openoffice. that's not possible anymore ... Oliver -- GnuPG key 0xCFD04A45: 8822 057F 4956 46D3 352C 1A06 4E2C AB40 CFD0 4A45 signature.asc Description: OpenPGP digital signature
Re: [dev] Proposal: SDK as optional package of the office installation
Hi Jürgen, I really like the idea to make the SDK an optional package of the default OOo installation package bundle. - Kai. On 10.04.2008 14:34 Uhr, Juergen Schmidt - Sun Germany - ham02 - Hamburg wrote: Hi, i have investigated a little bit into the SDK to make it working/running with the new 3 layer office - OO.org 3.0. The SDK as it is doesn't work with the new structure and i would like to propose to make the SDK as an *optional* package of the normal office installation because it would simplify the whole SDK usage and configuration a lot. It's no really new idea and i have it mind for a long time. But now it seems to be the perfect time because the old structure doesn't work anymore and have to be changed anyway. The only disadvantage so far is that the download becomes a little bit bigger. For the linux distros it shouldn't be a problem because they do it anyway on their own and for example on Ubuntu the SDK packages install already in a sub directory under the office installation. Some more reasons why i think it would be a good move 1. it would ease the use and the configuration of the SDK a lot 2. everything in place if you want to program with or for OO.org 3. the *big* DevGuide (html and PDF) are removed anyway since 2.4 - the DevGuide is in the wiki online available 4. we can include the API IDL reference in the office help system. It's currently completely missing. Macro programmer have only a StarBasic runtime help but no API reference. 5. examples becomes independent. In the long term i would prefer NetBeans, Eclipse and MS Studio example projects as separate downloads or in cvs and documented in the wiki. Example would be easier to use, easier to maintain. 6. the support of different IDE's would be also simplified What do you think? I would like to make this change for OO.org 3.0 and the visible impact is small. More or less only the GUI installer are effected and will offer tow additional optional installation options. Everything else should be minor issues. The impact for localization is small. Only two short names and descriptions for the new module sin the GUI installer. There is no need to translate the SDK completely. At least not for 3.0. From my point of view it doesn't make sense to translate the IDL reference. We can think about the other SDK html files but as mentioned before there is no need for 3.0. Please share your opinions as well as your complains for this proposal as soon as possible here on the list. Juergen - 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] Long paths on Windows
Oliver Brinzing wrote: Hi, spaces: no idea if that is good or bad; when coming up with Basis 3.0 I just followed prior art (OpenOffice.org 2.4) that's true, but till oo 2.4 one had a chance to install to a path without spaces and version numbering, like c:\programs\openoffice. that's not possible anymore ... Right. I'm rather indifferent about the exact naming details (apart from the technically-imposed version numbers encoded in file names, of course), maybe other people want to give input. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Long paths on Windows
Stephan Bergmann wrote: Applications on Windows are notorious for having problems with long file system paths. Some expert on Windows can probably give more insight into the topic in general. For OOo, the situation has always been that it can start to fail in mysterious ways if the installation path or the user installation path is too long (whatever too long is exactly). Since DEV300m4, the situation has become slightly worse, in that too long has apparently become a little shorter: - For one, since OOo is now in three layers where the upper layers need to create paths to the lower ones, on Windows there is now a function (resolveLink, desktop/win32/source/extendloaderenvironment.cxx:1.4, l. 115 ff) to create a new path from an absolute path and a text file containing a relative path. The text file (basis-link resp. ure-link) typically contains a relative path starting with one or more .. segments, but resolveLink does not bother to remove these from the resulting new path. That is, instead of the path C:\Program Files\OpenOffice.org\Basis 3.0\program you get the path C:\Program Files\OpenOffice.org 3.0\..\OpenOffice.org\Basis 3.0\program which is somewhat longer. I will see to improve resolveLink in one of the next milestone builds. see http://www.openoffice.org/issues/show_bug.cgi?id=88166 -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
