Fwd: appearance of the cursor (dimension, color, shape, flashing) in Apache Open Office Writer
-- Forwarded message -- From: Arnaldo Carbone arnycarb...@gmail.com Date: 2014-01-28 Subject: appearance of the cursor (dimension, color, shape, flashing) in Apache Open Office Writer To: d...@openoffice.org hi there to everybody! my proposal: to make possible to change the shape and the color of the cursor in Apache Open Office Writer (possibly also the dimension and the flashing velocity); it would be so pleasent to find easily the position of the cursor after somebody removes the glance from the screen! thank you. Arnaldo
Bottom up build
I would like to report some observations that I made when thinking about how to make building OpenOffice with one global makefile feasible. It will probably the last of build related mails in the near future. Traditional make uses a top-down approach. It starts with a target, 'all' by default, and looks at its dependencies. When one of those has to be made or is newer then the target then the target also has to be made. This is done recursively and depth-first. Every file on which 'all' has a direct or indirect dependency has to be checked. If we would build OpenOffice with one makefile (included makefiles don't count) then that are a lot of files to check. There are about 9800 cxx files, 3500 c files, 12000 hxx files, and lot of external headers. Checking the modification time of so many files is one of the reasons for the delay in , say, sw/ between starting make and its first action. As I don't have all global dependencies in a format that would allow experimation, I tried how long it would take to get the mtime (time of last modification) for all files, source, generated, compiled, linked, about 12. I wrote a small Java program for that. With a warm cache that takes about 23s. When run in 4 threads this reduced to less than 8s. Could be worse. But it also could be better because in general there are only a few files modified, usually files that you modified yourself in an editor. There is another approach, introduced, as far as I know, by the tup [1] build tool, that is bottom up. If you had something similar to the oracle of complexity theory, that gave you the list of modified files since the last build, you could find the depending files much faster. Faster for two reasons. Firstly, there is only one path in the dependency tree up towards the root (while there are many down from the root). Only targets on this path are affected by the modified file. Secondly, the dependency analysis is comparatively cheap. The expensive part is to determine the file modification times. If they where miraculously given then even the top-down approach would not take noticably longer. So I made another experiment to see if such an oracle can be created. Java 7 has the java.nio.file.WatchService that lets you monitor file modfifications in one directory. I registered it to all directories in our source tree (some 16000 directories). With the WatchService in place every file modification can be recorded and stored for later. On the next build you only have to check the set of modified files, not all files. Registering the directory watchers takes a couple of seconds but after that it does not cause any noticeable CPU activity. Any file modifications are reported almost at once. I do not have the framework in place to start a build with this information but I would expect it to be as fast as compiling the modified files and linking takes. The tup website references a paper [2] in which the established top-down approaches are called alpha alogithms and the new bottom-up approach is called beta algorithm. Tup has implemented a file modification watcher (in C or C++) only for Linux. On Windows it just scans all files (for which it needs a little more time than my Java program, maybe it does not use more than one thread). This is something that we should keep in mind for when we ever should get a build solution with global dependencies and this build tool would turn out to be too slow. If can find the source code of my Java experiments at [3]. If nothing else you can see an application of the ForkJoinPool that allowed my to write the parallel file system scan in just a few lines. There is also an alternative implementation that uses the ExecutorService (with a fixed thread pool) which needs a few more lines of code. And there is of course the use of the WatchService. Regards, Andre [1] http://gittup.org/tup/ [2] http://gittup.org/tup/build_system_rules_and_algorithms.pdf [3] http://people.apache.org/~af/test.zip - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: New SNAPSHOT available (based on r1560772)
On 28.01.2014 18:35, Andrea Pescetti wrote: On 27/01/2014 Herbert Duerr wrote: [2] http://people.apache.org/~hdu/developer-snapshots/snapshot/ I see that filenames look like Apache_OpenOffice_4.1.0_Linux_x86-64_install-rpm_it.tar.gz Shouldn't they have a m1 or some other identifier that identifies them as not final? Yes, I'd prefer that too. But up to now all such snapshots were named as like that (equal to the target version) and there wasn't too much confusion. We'll have a similar situation when we get to vote on the next release candidates. They HAVE to be named like the final version, even if they are only release candidates and may fail the vote. Temporarily renaming the release candidate install packages to contain rcN and naming them back to their final name might work. All the checksum and signature files have to be updated too then. I also suggest to rename the macos part of Mac packages to OSX (or osx). The name Mac OS [1] was dropped since Mac OS X and Mac OS X lost the Mac part since 10.7 (a.k.a. Lion). I thing that avoiding a space character between OS and X, because spaces in installation packages cause more trouble than adhering 100% to Apple's naming scheme. [1] http://en.wikipedia.org/wiki/Mac_OS [2] http://en.wikipedia.org/wiki/OSX I suggest to move this page into our MediaWiki instead where generated markup can be directly used. As you wish. No problem for me, of course. Actually, considering the audience, your link [2] above is just fine. I believe testers will be able to find what they need. Yes. The Wiki update is still in progress, Andre is working on a script to automate it for MediaWiki. Thanks to Kay's note about the enabled Html-Extension in the Confluence Wiki we could keep it there too though. This needs some more minor adjustments to the new script. I also suggest to use a different name for these kinds of snapshots, because the buildbots provide a different of snapshot [5] that are not built for maximum compatibility. How about renaming the release-like snapshots to milestone? Milestone is OK for me. And with an e.g. m1 marker we could say the 'm' is for milestone. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Bottom up build
On 29 January 2014 10:18, Andre Fischer awf@gmail.com wrote: I would like to report some observations that I made when thinking about how to make building OpenOffice with one global makefile feasible. It will probably the last of build related mails in the near future. Traditional make uses a top-down approach. It starts with a target, 'all' by default, and looks at its dependencies. When one of those has to be made or is newer then the target then the target also has to be made. This is done recursively and depth-first. Every file on which 'all' has a direct or indirect dependency has to be checked. If we would build OpenOffice with one makefile (included makefiles don't count) then that are a lot of files to check. There are about 9800 cxx files, 3500 c files, 12000 hxx files, and lot of external headers. Checking the modification time of so many files is one of the reasons for the delay in , say, sw/ between starting make and its first action. As I don't have all global dependencies in a format that would allow experimation, I tried how long it would take to get the mtime (time of last modification) for all files, source, generated, compiled, linked, about 12. I wrote a small Java program for that. With a warm cache that takes about 23s. When run in 4 threads this reduced to less than 8s. Could be worse. But it also could be better because in general there are only a few files modified, usually files that you modified yourself in an editor. There is another approach, introduced, as far as I know, by the tup [1] build tool, that is bottom up. If you had something similar to the oracle of complexity theory, that gave you the list of modified files since the last build, you could find the depending files much faster. Faster for two reasons. Firstly, there is only one path in the dependency tree up towards the root (while there are many down from the root). Only targets on this path are affected by the modified file. Secondly, the dependency analysis is comparatively cheap. The expensive part is to determine the file modification times. If they where miraculously given then even the top-down approach would not take noticably longer. So I made another experiment to see if such an oracle can be created. Java 7 has the java.nio.file.WatchService that lets you monitor file modfifications in one directory. I registered it to all directories in our source tree (some 16000 directories). With the WatchService in place every file modification can be recorded and stored for later. On the next build you only have to check the set of modified files, not all files. Registering the directory watchers takes a couple of seconds but after that it does not cause any noticeable CPU activity. Any file modifications are reported almost at once. I do not have the framework in place to start a build with this information but I would expect it to be as fast as compiling the modified files and linking takes. The tup website references a paper [2] in which the established top-down approaches are called alpha alogithms and the new bottom-up approach is called beta algorithm. Tup has implemented a file modification watcher (in C or C++) only for Linux. On Windows it just scans all files (for which it needs a little more time than my Java program, maybe it does not use more than one thread). This is something that we should keep in mind for when we ever should get a build solution with global dependencies and this build tool would turn out to be too slow. If can find the source code of my Java experiments at [3]. If nothing else you can see an application of the ForkJoinPool that allowed my to write the parallel file system scan in just a few lines. There is also an alternative implementation that uses the ExecutorService (with a fixed thread pool) which needs a few more lines of code. And there is of course the use of the WatchService. Thanks for writing down your observations which I find highly interesting. I hope your stop on writing about build does not include giving your opinion on my ideas in the future as well. For the record the capstone project, and my little hobby project Build R.I.P. follow a third idea: We have a clear seperation of module build and central (total) build. The module makefile knows how to build the module, and the central makefile knows the relation between modules. The makefile in each module touched a file, and the central makefile only controls that file. But youir idea of watching for changes is very interesting. rgds jan I. Andre [1] http://gittup.org/tup/ [2] http://gittup.org/tup/build_system_rules_and_algorithms.pdf [3] http://people.apache.org/~af/test.zip - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
review granted: [Bug 124065] [Performance] Low performance opening attached .ods : [Attachment 82409] New Fix
Andre awf@googlemail.com has granted wujinl...@gmail.com's request for review: Bug 124065: [Performance] Low performance opening attached .ods https://issues.apache.org/ooo/show_bug.cgi?id=124065 Attachment 82409: New Fix https://issues.apache.org/ooo/attachment.cgi?id=82409action=edit --- Additional Comments from Andre awf@googlemail.com Review granted. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
UK government preparing to switch to AOO?
http://www.theguardian.com/technology/2014/jan/29/uk-government-plans-switch-to-open-source-from-microsoft-office-suite -- Ian Ofqual Accredited IT Qualifications https://theingots.org/community/faq#7.0 Headline points in the 2014, 2015, 2016 school league tables www.th http://www.theINGOTs.org*elearningmachine.co.uk http://elearningmachine.co.uk* +44 (0)1827 305940 The Learning Machine Limited, Reg Office, Unit 4D Gagarin, Lichfield Road Industrial Estate, Tamworth, Staffordshire, B79 7GN. Reg No: 05560797, Registered in England and Wales.
Re: looking for help
https://forum.openoffice.org/en/forum/viewtopic.php?f=9t=43621hilit=print+gridlines - Mail original - De: Satya Sharma spu...@shaw.ca À: dev@openoffice.apache.org Envoyé: Mardi 28 Janvier 2014 19:57:14 Objet: looking for help Have started using Apache spreadshet, a very veratile indeed! However would appreciate help in its use.e.g; how to print gridlines? Tnx. Satya. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: UK government preparing to switch to AOO?
On Wed, Jan 29, 2014 at 5:38 AM, Ian Lynch ianrly...@gmail.com wrote: http://www.theguardian.com/technology/2014/jan/29/uk-government-plans-switch-to-open-source-from-microsoft-office-suite -- Nice. It sounds like the Cabinet Office Minister was talking about open standards, but that got conflated in the article with open source. I cringe a little when I see phrases like open-source files . But where open standards are adopted then open source programs like OpenOffice compete on a more level playing field, so this is all good. -Rob Ian Ofqual Accredited IT Qualifications https://theingots.org/community/faq#7.0 Headline points in the 2014, 2015, 2016 school league tables www.th http://www.theINGOTs.org*elearningmachine.co.uk http://elearningmachine.co.uk* +44 (0)1827 305940 The Learning Machine Limited, Reg Office, Unit 4D Gagarin, Lichfield Road Industrial Estate, Tamworth, Staffordshire, B79 7GN. Reg No: 05560797, Registered in England and Wales. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: UK government preparing to switch to AOO?
Depends on how much is rhetoric and how much gets translated into practice. I'll try and find out more and give nudges in the right direction. Two things are in our favour. Microsoft has waning importance with the rise of Google and Apple in particular and this makes people a bit less averse to the risk of change. The government is desperate to demonstrate strategies to save money to reduce the budget deficit in ways other than cutting public services. On 29 January 2014 12:53, Rob Weir robw...@apache.org wrote: On Wed, Jan 29, 2014 at 5:38 AM, Ian Lynch ianrly...@gmail.com wrote: http://www.theguardian.com/technology/2014/jan/29/uk-government-plans-switch-to-open-source-from-microsoft-office-suite -- Nice. It sounds like the Cabinet Office Minister was talking about open standards, but that got conflated in the article with open source. I cringe a little when I see phrases like open-source files . But where open standards are adopted then open source programs like OpenOffice compete on a more level playing field, so this is all good. -Rob Ian Ofqual Accredited IT Qualifications https://theingots.org/community/faq#7.0 Headline points in the 2014, 2015, 2016 school league tables www.th http://www.theINGOTs.org*elearningmachine.co.uk http://elearningmachine.co.uk* +44 (0)1827 305940 The Learning Machine Limited, Reg Office, Unit 4D Gagarin, Lichfield Road Industrial Estate, Tamworth, Staffordshire, B79 7GN. Reg No: 05560797, Registered in England and Wales. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Ian Ofqual Accredited IT Qualifications https://theingots.org/community/faq#7.0 Headline points in the 2014, 2015, 2016 school league tables www.th http://www.theINGOTs.org*elearningmachine.co.uk http://elearningmachine.co.uk* +44 (0)1827 305940 The Learning Machine Limited, Reg Office, Unit 4D Gagarin, Lichfield Road Industrial Estate, Tamworth, Staffordshire, B79 7GN. Reg No: 05560797, Registered in England and Wales.
32-Bit MacOSX Snapshot available too, somewhere ? (Re: New SNAPSHOT available (based on r1560772)
On 27.01.2014 12:02, Herbert Duerr wrote: New snapshot builds based on the feature freeze revision (according to the release plan [1]) are available at [2]. [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning [2] http://people.apache.org/~hdu/developer-snapshots/snapshot/ The development-snapshot CWiki page [3] has been partially updated, but since Markup was disabled [4] in the latest Confluence update the process of updating this page has become incredibly painful and will take some more time. [3] https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds [4] http://blogs.atlassian.com/2011/11/why-we-removed-wiki-markup-editor-in-confluence-4/ I suggest to move this page into our MediaWiki instead where generated markup can be directly used. I also suggest to use a different name for these kinds of snapshots, because the buildbots provide a different of snapshot [5] that are not built for maximum compatibility. How about renaming the release-like snapshots to milestone? [5] http://ci.apache.org/projects/openoffice/#linsnap [3] points to a non-existing 32-bit version of the 4.1 MacOSX snapshot. Using [2] allows me to get to a 64-bit verison of the 4.1 MacOSX snapshot. As all my tests in the past have been against 32-bit, I would like to do them with the latest snapshot as well against the 32-bit version. So, is there any pointer to a 32-bit version too, or is the plan to release 4.1 on MacOSX in 64-bit only? TIA, ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: 32-Bit MacOSX Snapshot available too, somewhere ? (Re: New SNAPSHOT available (based on r1560772)
On 1/29/14 3:30 PM, Rony G. Flatscher wrote: On 27.01.2014 12:02, Herbert Duerr wrote: New snapshot builds based on the feature freeze revision (according to the release plan [1]) are available at [2]. [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning [2] http://people.apache.org/~hdu/developer-snapshots/snapshot/ The development-snapshot CWiki page [3] has been partially updated, but since Markup was disabled [4] in the latest Confluence update the process of updating this page has become incredibly painful and will take some more time. [3] https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds [4] http://blogs.atlassian.com/2011/11/why-we-removed-wiki-markup-editor-in-confluence-4/ I suggest to move this page into our MediaWiki instead where generated markup can be directly used. I also suggest to use a different name for these kinds of snapshots, because the buildbots provide a different of snapshot [5] that are not built for maximum compatibility. How about renaming the release-like snapshots to milestone? [5] http://ci.apache.org/projects/openoffice/#linsnap [3] points to a non-existing 32-bit version of the 4.1 MacOSX snapshot. Using [2] allows me to get to a 64-bit verison of the 4.1 MacOSX snapshot. As all my tests in the past have been against 32-bit, I would like to do them with the latest snapshot as well against the 32-bit version. So, is there any pointer to a 32-bit version too, or is the plan to release 4.1 on MacOSX in 64-bit only? as discussed already on the list here some weeks ago, we won't have a 32bit version of AOO 4.1. We migrate to newer APIs because the older ones are already deprecated by Apple. The maintenance effort for us is too high but we said that we will support anybody who is interested to work on this. Juergen TIA, ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: 32-Bit MacOSX Snapshot available too, somewhere ? (Re: New SNAPSHOT available (based on r1560772)
On 29.01.2014 16:23, Jürgen Schmidt wrote: On 1/29/14 3:30 PM, Rony G. Flatscher wrote: On 27.01.2014 12:02, Herbert Duerr wrote: New snapshot builds based on the feature freeze revision (according to the release plan [1]) are available at [2]. [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning [2] http://people.apache.org/~hdu/developer-snapshots/snapshot/ The development-snapshot CWiki page [3] has been partially updated, but since Markup was disabled [4] in the latest Confluence update the process of updating this page has become incredibly painful and will take some more time. [3] https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds [4] http://blogs.atlassian.com/2011/11/why-we-removed-wiki-markup-editor-in-confluence-4/ I suggest to move this page into our MediaWiki instead where generated markup can be directly used. I also suggest to use a different name for these kinds of snapshots, because the buildbots provide a different of snapshot [5] that are not built for maximum compatibility. How about renaming the release-like snapshots to milestone? [5] http://ci.apache.org/projects/openoffice/#linsnap [3] points to a non-existing 32-bit version of the 4.1 MacOSX snapshot. Using [2] allows me to get to a 64-bit verison of the 4.1 MacOSX snapshot. As all my tests in the past have been against 32-bit, I would like to do them with the latest snapshot as well against the 32-bit version. So, is there any pointer to a 32-bit version too, or is the plan to release 4.1 on MacOSX in 64-bit only? as discussed already on the list here some weeks ago, we won't have a 32bit version of AOO 4.1. We migrate to newer APIs because the older ones are already deprecated by Apple. The maintenance effort for us is too high but we said that we will support anybody who is interested to work on this. That's fine, I followed the discussion but have not realized that the switch to 64-bit on MacOSX is with 4.1. Nevertheless, the link from [3] should be adjusted accordingly. ---rony - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: switch trunk from Mac 32bit to 64bit
Am 01/29/2014 08:43 AM, schrieb Andre Fischer: On 28.01.2014 23:18, Marcus (OOo) wrote: Am 12/19/2013 05:58 PM, schrieb jan i: On 19 December 2013 17:29, Herbert Duerrhdu_...@alice.de wrote: The new Mac port looks quite good. I uploaded a current version to my page [1]. Jürgen already mentioned it will only work for OSX 10.7 and up. It is based on todays trunk, which already contains a lot of fixes and enhancements compared to our latest release. For details you can have a look at our progress tracking page [2]. [1] http://people.apache.org/~hdu/ [2] http://people.apache.org/~hdu/izlist9.htm In the early days of next year I plan to update our trunk so the new port becomes active. To build it yourself you'll need XCode4 then. XCode4 comes with the 10.7 SDK. +1 the wiki build instructions should also be updated. I've created a new webpage for sys reqs: http://ooo-site.staging.apache.org/dev_docs/source/sys_reqs_aoo41.html Thanks, great work. Maybe we should not state so prominently that we are not Windows 8 certified. We don't have the goal to be and probably never will. As far as I know we also not certified on any other Windows, or any other OS. For the first step I've just modified the Mac things, just to make sure it will not be forgotten. For the Win certification, in the past we had some users who ask for this. We simply referred them to the sys regs. So, in general IMHO it's helping to have it. I've changed the wording a bit. Is it now better? Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
We've recently compiled OpenOffice 4.01 on Solaris 11 x86 and are experiencing the following at runtime. I've included some of the stack trace below. Any help would be great. Thanks! Observed Behaviour 1.OpenOffice starts, the splash screen with logo appears and then closes replaced with the full application window and choices for specific OpenOffice projects. 2.Selecting either the Word or Spreadsheet project causes a segmentation fault and closes the application. 3.Following the start of the application with the debugger, we can see the SidebarController is created in a first pass without error (known because first time to this stop point does not error). 4.As the process continues, the SidebarController constructor is called a second time (unknown why, but could be understood with more familiarity with the system). 5.The failure doesn't appear in the constructor, but the trace follows down SidebarController constructor call of WeakReferenceSidebarController WeakController (this); 6.This template definition for WeakController uses ReferenceTemplate::Refrence( interface_type *pInterface) as its definition in ::com::sun::star::uno::Reference.hxx. 7.The function will try to convert the pInterface parameter to a XInterface type called _pInterface. 8.If it succeeds in converting the pInterface to _pInterface then the function will try to acquire a new reference. 9.Assumption: Creating this new reference calls SidebarController::notifyContextChangeEvent with a corrupt or bad rEvent. This assumption is based on the stack where the immediate next routine after the Reference function call is the notifyContextChangeEvent, also while following along in the debugger, the rEvent parameter at this point is already corrupted with the value ERROR stored in the structure. 10. It is later after the notifyContextChangeEvent calls Context and then ustring that the segmentation fault occurs, but I believe the error located in rEvent is what causes this later problem. It appears as if inside the SidebarController Constructor at line 168 when xWeakController(this) is called that the problem first occurs. The xWeakController appears to be defined in Reference.hxx in /cppu/inc/com/sun/star/uno/ and this definition as an inline function that calls the _pInterface-acquire() at line 136. We assume that this acquire is where the problem occurs because the SidebarController::notifyContextChangeEvent (which is the next item on the stack) rEvent contains an ERROR value in the dbxtool (debug tool) immediately following in the stack. It eventually crashes downstream at line 103 of ustring.hxx in /sal/inc/rtl when the string is trying to be accessed as pData = str.pData; Stack Trace: (dbx) where current thread: t@1 =[1] rtl::OUString::OUString(this = 0xfeff9dac, str = CLASS), line 103 in ustring.hxx [2] sfx2::sidebar::Context::Context(this = 0xfeff9dac, rsApplication = CLASS, rsContext = CLASS), line 51 in Context.cxx [3] sfx2::sidebar::SidebarController::notifyContextChangeEvent(this = 0xebc6d6b0, rEvent = STRUCT), line 257 in SideBarController.cxx [4] com::sun::star::uno::Referencesfx2::sidebar::SidebarController::Reference(this = 0xfeff9f64, pInterface = 0xebc6d6b0), line 136 in Reference.hxx [5] sfx2::sidebar::SidebarController::SidebarController(this = 0xebc6d6b0, pParentWindow = 0x9659bf8, rxFrame = CLASS), line 168 in SidebarController.cxx I can provide more of the stack trace if needed. Thanks in Advance! Raymond
scripts to assist in editing helpcontent2
I decided to assist with the task of adding help information the four functions added to scalc some time ago (see mail thread: http://markmail.org/message/ojaxtd6uez4wk3rf) so I fist tracked down the help files in which to add the information. Then a major stumbling block -- how to create the needed header ids, bookmark ids, paragraph ids for my proposed additions. I ended up constructing a script that went through all the help files and culled out the ids that had already been used producing 3 little files corresponding to header ids, bookmark ids and paragraph ids, thinking new ones could be chosen using these lists. Really crazy results -- not all nice numerical id sequences but oh well. Anyway, where's a good place for this if someone else needs to use them? I think the wiki takes attachments? Should I just upload there along with some instructions for use? -- - MzK Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect. -- James Mason
RE: New SNAPSHOT available (based on r1560772)
Put it in the 'doesn't it figure' category, but can I solicit support for another build cycle for the all language feature freeze SNAPSHOT. There is a major flaw in the IAccessible2 code, i124095, that got patched by Mick Curran and Steve Yin with revision 1561587, and is available in en-US and de on the nightly Windows builds. Unfortunately, leaving the r1560772 SNAPSHOT will result is skewed testing results and opinions regards one of the major new features of the 4.1.0 release -- IAccessible2 support. It is painful but the SNAPSHOT really should be respun. Sorry. Stuart
Re: switch trunk from Mac 32bit to 64bit
Hi Markus, below you find the output of my iMac running Mac OS X 10.7 From my point of view it should be assured that Mac users running Mac OS X 10.6 or earlier are _not_ directed to a download of AOO 4.1. Instead they should be directed to AOO 4.0.1 together with a note saying that AOO 4.1 needs Mac OS X version 10.7 or later. Best regards, Oliver. FIREFOX Browser variables Values navigator.appCodeName Mozilla navigator.appName Netscape navigator.appVersion5.0 (Macintosh) navigator.platform MacIntel navigator.oscpu Intel Mac OS X 10.7 navigator.cpuClass undefined navigator.product Gecko navigator.productSub20100101 navigator.vendor navigator.vendorSub navigator.language de-DE navigator.browserLanguage undefined navigator.userLanguage undefined navigator.systemLanguageundefined navigator.userAgent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:26.0) Gecko/20100101 Firefox/26.0 JavaScript functions/variables Values Language name Deutsch Language ISO code de Language array data de,German,Deutsch,y,http://www.openoffice.org/de/ Release matrix platform position8 Release matrix platform array data Mac_x86_install,y,182,Apache_OpenOffice_4.0.1_MacOS_x86_install_de.dmg UI platform nameOS X 32-bit Intel (DMG) URL platform name Mac_x86_install File name Apache_OpenOffice_4.0.1_MacOS_x86_install_de.dmg File extension .dmg File size 182 Download file link http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.1/binaries/de/Apache_OpenOffice_4.0.1_MacOS_x86_install_de.dmg/download Checksum file link (here for MD5) http://www.apache.org/dist/openoffice/4.0.1/binaries/de/Apache_OpenOffice_4.0.1_MacOS_x86_install_de.dmg.md5 hasMirrorLink() true getLink() http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.1/binaries/de/Apache_OpenOffice_4.0.1_MacOS_x86_install_de.dmg/download General error false SAFARI Browser variablesValues navigator.appCodeNameMozilla navigator.appNameNetscape navigator.appVersion5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.73.11 (KHTML, like Gecko) Version/6.1.1 Safari/537.73.11 navigator.platformMacIntel navigator.oscpuundefined navigator.cpuClassundefined navigator.productGecko navigator.productSub20030107 navigator.vendorApple Computer, Inc. navigator.vendorSub navigator.languagede-de navigator.browserLanguageundefined navigator.userLanguageundefined navigator.systemLanguageundefined navigator.userAgentMozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.73.11 (KHTML, like Gecko) Version/6.1.1 Safari/537.73.11 JavaScript functions/variablesValues Language nameDeutsch Language ISO codede Language array datade,German,Deutsch,y,http://www.openoffice.org/de/ Release matrix platform position8 Release matrix platform array data Mac_x86_install,y,182,Apache_OpenOffice_4.0.1_MacOS_x86_install_de.dmg UI platform nameOS X 32-bit Intel (DMG) URL platform nameMac_x86_install File nameApache_OpenOffice_4.0.1_MacOS_x86_install_de.dmg File extension.dmg File size182 Download file link http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.1/binaries/de/Apache_OpenOffice_4.0.1_MacOS_x86_install_de.dmg/download Checksum file link (here for MD5) http://www.apache.org/dist/openoffice/4.0.1/binaries/de/Apache_OpenOffice_4.0.1_MacOS_x86_install_de.dmg.md5 hasMirrorLink()true getLink() http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.1/binaries/de/Apache_OpenOffice_4.0.1_MacOS_x86_install_de.dmg/download General errorfalse On 28.01.2014 23:24, Marcus (OOo) wrote: Am 12/20/2013 02:47 PM, schrieb Herbert Duerr: On 19.12.2013 17:58, jan i wrote: On 19 December 2013 17:29, Herbert Duerr hdu_...@alice.de wrote: The new Mac port looks quite good. I uploaded a current version to my page [1]. Jürgen already mentioned it will only work for OSX 10.7 and up. It is based on todays trunk, which already contains a lot of fixes and enhancements compared to our latest release. For details you can have a look at our progress tracking page [2]. [1] http://people.apache.org/~hdu/ [2] http://people.apache.org/~hdu/izlist9.htm In the early days of next year I plan to update our trunk so the new port becomes active. To build it yourself you'll need XCode4 then. XCode4 comes with the 10.7 SDK. +1 the wiki build instructions should also be updated. +1 Do we also need to update information on the download page (e.g. that we only support OSX 10.7 and up) ? As Jürgen already mentioned the installation files are already protected. We should also update the release notes, etc. If it is possible to know the OS version from e.g. the browser's User Agent then we should update the download page too. Maybe we already have such a mechanism. Does anyone happen to have OSX 10.3 or earlier? What happens
