Re: OpenOffice development with Eclipse
On 12/19/13 7:54 AM, Abhishek Kumar wrote: Hello Andre and Jürgen, I have recently started working with OpenOffice, and wanted to get into deeper details of the massive codebase. Although I am used to working with vim+gnuToochain, but given the codebase size, an IDE for indexing and viewing the code seems to be a good way forward for someone new to this codebase. Eclipse as specified here seems to be quite good for debugging and viewing code. Is there some standard IDE that is used for debugging/editing core OO code in SC/SD/WriterFilter etc? on Windows the MS Dev Studio Express Edition is used normally, the Ms debugger is the best I have seen so far. On Mac I use gdb in Emacs or Xcode. Especially with the new Mac env I will use Xcode. On Linux I haven't seen a very good tool wrapping the gdb. I use gdb in Emacs or via command line but will try in the future Eclipse. Juergen Thanks, Abhishek On Tue, Dec 17, 2013 at 3:04 PM, Jürgen Schmidt jogischm...@gmail.comwrote: On 12/17/13 9:58 AM, Andre Fischer wrote: Hi, About a week or so ago I tried again to import the OpenOffice source code into Eclipse. The last time I tried that, a few years ago, this did not work at all. Our source code was just to big and too complex. This time however, it worked out of the box. If you do it right :-) The developers of the CDT (the C/C++ Development Tooling) have made great progress in the last years. As this allows newcomers a much easier way to become OpenOffice developers and also can make the work of experienced developers more productive I would like to share how to set up Eclipse for OpenOffice. This process is still a bit rough around the edges. Any help is appreciated. I have started a Wiki page [1] which explains the manual setup. It should work on all platforms but at the moment only Windows is described. Maybe you can help to fill in missing values for other platforms. I am working on a few Eclipse plugins to automate this process: - A wizard for setting up an Eclipse workspace. The prototype has just to be pointed to the (compiled) source code. It will then collect all the necessary include paths and set the necessary compiler defines so that the indexer can resolve even the platform dependent definitions. This is important because even something as simple as sal_Int16 will not be recognized without the indexer being told about platform specific preprocessor defines. - The idea of CDT about how C/C++ files are built is different from how OpenOffice does it. Therefore I am developing a short term solution that provides a couple of buttons/menu entries/whatever will be appropriate to build the current module, directory or file and then deploy the new libraries into an installed office. Here are some highlight of what Eclipse and CDT allow us to do: - Easily switch between header and implementation file. - Follow header inclusion (just Ctrl-click on an #include statement and the referenced header file is opened in the editor. - Get information about variables and classes by simply hovering over their names. A popup box shows you the variable definition or the class implementation. That is something you have to see to believe it. - Find out from where a function or method is called - Explore the type hierarchy of a class. - Macro expansion. Hover over a macro use and see the expansion of it, several iterations if necessary. Ever wanted to know how IMPL_LINK is defined? Just move your mouse pointer over it. - Code assist while typing. Define a variable, eg. ::rtl::OUString sText Then type sText., wait a little (default is 500ms) and a box shows you all the available methods of OUString. - An overview at the right side shows you all the functions, methods, includes, macro defines etc, that are made in the currently edited file. Click on one and jump to the corresponding source code. All of this may sound familiar to Java developers. But for C++, especially for OpenOffice, I think this is quite remarkable. And to underline what Andre has described above, this is really cool and we are sure it will help us a lot. I watched a video from Bjoern Michaelsen from LO where he presented something similar for KDevelop and pointed out what's possible with their new complete gbuild system I didn't understand the relation between the build system and the integration and talked with Andre about and others about it. Andre who is quite familiar with Eclipse (I am more a NetBeans guy) spend a first hour on experimenting with Eclipse. We didn't knew that and after an hour he presented us the first results which were impressive. I did a similar test on my Mac with the same result and was able to compile and debug (old gcc env) in Eclipse. Well I had some problems with the new upcoming env (clang, lldb) because there is no lldb tool chain for Eclipse yet. But anyway the whole support and the
Re: createRegistryServiceFactory: cannot get uno environments!
Hello Απόστολος,
On 18.12.2013 18:39, Απόστολος Συρόπουλος wrote:
Anyway, if we're lucky the problem is just a missing library or the failed
loading
of a library. In that case the patch below might help you to analyze the
problem:
Indeed the problem is a missing library:
:
LD_LIBRARY_PATH=/extra/sources/OpenOffice/aoo4/main/solver/410/unxsogi.pro/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
../../../unxsogi.pro/bin/saxparser en_AU en_AU.xml
../../../unxsogi.pro/misc/localedata_en_AU.cxx \
file:///extra/sources/OpenOffice/aoo4/main/i18npool/source/localedata/data/../../../unxsogi.pro/misc/saxparser.rdb
/extra/sources/OpenOffice/aoo4/main/solver/410/unxsogi.pro/bin/types.rdb \
-env:OOO_INBUILD_SHAREDLIB_DIR=file:///extra/sources/OpenOffice/aoo4/main/solver/410/unxsogi.pro/lib
loadModule(
/extra/sources/OpenOffice/aoo4/main/solver/410/unxsogi.pro/lib/libg++_uno.so,
257) failed with ld.so.1: saxparser: fatal:
/extra/sources/OpenOffice/aoo4/main/solver/410/unxsogi.pro/lib/libg++_uno.so: open
failed: No such file or directory
loadModule(
/extra/sources/OpenOffice/aoo4/main/solver/410/unxsogi.pro/lib/libg++_uno.so,
257) failed with ld.so.1: saxparser: fatal:
/extra/sources/OpenOffice/aoo4/main/solver/410/unxsogi.pro/lib/libg++_uno.so: open
failed: No such file or directory
Exception on createRegistryServiceFactory: cannot get uno environments!
dmake: Error code 1, while making
'../../../unxsogi.pro/misc/localedata_en_AU.cxx'
Google returns nothing about libg++_uno...
A library like that should be automatically built as one of the bridges
in main/bridge/source/cppu_uno/. In your case the gcc3_solaris_intel
bridge might be a good candidate but as the name says it probably builds
a libgcc3_uno.so instead of the libg++_uno.so your other binaries
expect. Check the makefile.mk in the bridge. Or find out why your
binaries look for a libg++_uno.so instead of a libgcc3_uno.so.
Herbert
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: OpenOffice development with Eclipse
Am 18.12.2013 20:33, schrieb Andrea Pescetti: Jürgen Schmidt wrote: We will blog about it in the new year and I ma sure we can then present a little bit more. This may be an interesting topic for FOSDEM too and I think you (Andre included, obviously!) already have quite clear ideas, so you could submit it as explained in https://blogs.apache.org/OOo/entry/join_apache_openoffice_at_fosdem by the Dec 22 deadline... unless you have already done it! I have written two proposals, and the Eclipse support is one of them. I am also working towards a blog post. But first I would like to finish a couple of Eclipse addons that make the OpenOffice integration a little easier. Christmas may slow me down a bit :-) In the mean time there is the Wiki page, now with some screenshots and a section about the Mylyn (Bugzilla) integration. -Andre Regards, Andrea. - 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: OpenOffice development with Eclipse
Hi, On 17.12.2013 09:58, Andre Fischer wrote: Hi, About a week or so ago I tried again to import the OpenOffice source code into Eclipse. The last time I tried that, a few years ago, this did not work at all. Our source code was just to big and too complex. This time however, it worked out of the box. If you do it right :-) The developers of the CDT (the C/C++ Development Tooling) have made great progress in the last years. As this allows newcomers a much easier way to become OpenOffice developers and also can make the work of experienced developers more productive I would like to share how to set up Eclipse for OpenOffice. This process is still a bit rough around the edges. Any help is appreciated. I have started a Wiki page [1] which explains the manual setup. It should work on all platforms but at the moment only Windows is described. Maybe you can help to fill in missing values for other platforms. I am working on a few Eclipse plugins to automate this process: - A wizard for setting up an Eclipse workspace. The prototype has just to be pointed to the (compiled) source code. It will then collect all the necessary include paths and set the necessary compiler defines so that the indexer can resolve even the platform dependent definitions. This is important because even something as simple as sal_Int16 will not be recognized without the indexer being told about platform specific preprocessor defines. - The idea of CDT about how C/C++ files are built is different from how OpenOffice does it. Therefore I am developing a short term solution that provides a couple of buttons/menu entries/whatever will be appropriate to build the current module, directory or file and then deploy the new libraries into an installed office. Here are some highlight of what Eclipse and CDT allow us to do: - Easily switch between header and implementation file. - Follow header inclusion (just Ctrl-click on an #include statement and the referenced header file is opened in the editor. - Get information about variables and classes by simply hovering over their names. A popup box shows you the variable definition or the class implementation. That is something you have to see to believe it. - Find out from where a function or method is called - Explore the type hierarchy of a class. - Macro expansion. Hover over a macro use and see the expansion of it, several iterations if necessary. Ever wanted to know how IMPL_LINK is defined? Just move your mouse pointer over it. - Code assist while typing. Define a variable, eg. ::rtl::OUString sText Then type sText., wait a little (default is 500ms) and a box shows you all the available methods of OUString. - An overview at the right side shows you all the functions, methods, includes, macro defines etc, that are made in the currently edited file. Click on one and jump to the corresponding source code. All of this may sound familiar to Java developers. But for C++, especially for OpenOffice, I think this is quite remarkable. Yes, it is - I will definitely try it out. Thanks for the sharing your findings. Best regards, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: AOO is now also available as GIT (READ-ONLY).
On 19 December 2013 11:22, Herbert Duerr h...@apache.org wrote: On 18.12.2013 18:38, jan i wrote: Infra-5590 has now been solved, thanks to an effort from jfarrell: jfarrell 16:11:32 janIV: christmas gift for you. took a little over a week to wrap, had to use duct tape along the way. git ls-remote git:// git.apache.org/openoffice.git Please have a look at our new READ-ONLY git mirror. That's great news, thanks! Kudos to Jake. Having a reference git-repository will allow us to do some nifty things: I'll prepare some git-packs with pre-AOO history from its older Mercurial, Subversion and maybe even from its CVS-based open-source ancestors. Using git's graft facilities this will make it much easier to research the history of parts of the codebase where noone is left to tell the story or its details. Having the individual commit comments and their issue numbers is invaluable then. Is there a gitweb or similar frontend to our git-mirror? Then we could e.g. provide a link from the nightly builds to their respective version history. As expected in my JIRA-request the two-level deep svn-branches (i.e. alg/aw080 and alg/sysdepgs) have been munged into one git-branch... We have anyhow to consider it the GIT branch is a practial solution, I just did a branch switch and encountered 2 problem: 1. The switch alone to 20 minutes 2. I had to rebuilt everything because (in my case) unxlngx6.pro is used for trunk and branch. We can with a relative simple patch platform= to configure avoid 2, but 1 is going to be PITN. Also the symphony branch is missing because it was checked into svn at a non-canonic location so the git-mirror couldn't pick it up. If those branches are changed to normal, the mirror should pick it up. Once everybody is happy, we can consider moving fully to GIT, I will however recommend to it imidiatly after next release. I'll have to adjust the svn2bz bot, we'll have to adjust the buildbots and there are some other scripts that have to be updated before we can think about a full switch. But I look forward to git's proper author attributions, interactive rebasing, intact individual commits after merges, nice cherry-picks, etc. I think we should have a discussion on the list. I am convinced that git offer some advantages but also some disadvantages (like branch switching) and I feel everybody should have a clear view of pro/con before we decide. rgds jan I. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: AOO is now also available as GIT (READ-ONLY).
Hello Jan, On 19.12.2013 15:37, jan i wrote: We have anyhow to consider it the GIT branch is a practial solution, I just did a branch switch and encountered 2 problem: 1. The switch alone to 20 minutes A svn switch between two branches takes about the same time, doesn't it? Window's file access is unfortunately quite slow. On Linux or on Mac the filesystems are no bottleneck so checkouts don't take long. 2. I had to rebuilt everything because (in my case) unxlngx6.pro is used for trunk and branch. Well, if trunk and branch are incompatible (i.e. some project wide headers changed, build options changed or there are binary incompatibilites between some libs) then you need clean rebuilds or different output trees regardless of the version control system. Does subversion have some magic that makes such incompatibilities go away? If there is such a magic then that would certainly be nobel price worthy ;-) But maybe you are using a different setup for your svn repos? Do you have one checkout per branch you are interested in? You can do the same with git of course and with git-clone's --reference option you can even share the meat of the different repositories, which is something very nice that I missed in Mercurial or now in Subversion. We can with a relative simple patch platform= to configure avoid 2, but 1 is going to be PITN. Also the symphony branch is missing because it was checked into svn at a non-canonic location so the git-mirror couldn't pick it up. If those branches are changed to normal, the mirror should pick it up. Yes. But I look forward to git's proper author attributions, interactive rebasing, intact individual commits after merges, nice cherry-picks, etc. I think we should have a discussion on the list. I am convinced that git offer some advantages but also some disadvantages (like branch switching) and I feel everybody should have a clear view of pro/con before we decide. +1 Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
switch trunk from Mac 32bit to 64bit
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. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: AOO is now also available as GIT (READ-ONLY).
On 19 December 2013 16:28, Herbert Duerr h...@apache.org wrote: Hello Jan, On 19.12.2013 15:37, jan i wrote: We have anyhow to consider it the GIT branch is a practial solution, I just did a branch switch and encountered 2 problem: 1. The switch alone to 20 minutes A svn switch between two branches takes about the same time, doesn't it? Window's file access is unfortunately quite slow. On Linux or on Mac the filesystems are no bottleneck so checkouts don't take long. The difference (of course I might use git wrongly), is the in svn, the branch is stored in its directory. With git I same disk space (trunk and branches are in 1 directory) but it needs to write a lot of files. 2. I had to rebuilt everything because (in my case) unxlngx6.pro is used for trunk and branch. Well, if trunk and branch are incompatible (i.e. some project wide headers changed, build options changed or there are binary incompatibilites between some libs) then you need clean rebuilds or different output trees regardless of the version control system. Does subversion have some magic that makes such incompatibilities go away? If there is such a magic then that would certainly be nobel price worthy ;-) He, I think it boils down to what I wrote in 1). Git standard keeps trunk/branches in one directory, and for small projects its very fast to switch. I have managed with a trix to have a git trunk in one directory and a git branch in another directory. However when I read the git manual that is not how its supposed to work. But maybe you are using a different setup for your svn repos? Do you have one checkout per branch you are interested in? You can do the same with git of course and with git-clone's --reference option you can even share the meat of the different repositories, which is something very nice that I missed in Mercurial or now in Subversion. I have the setup: /x1/aoo/trunk /x1/aoo/branches so one big aoo directory with everything (I have asked svn to ignore the branches am not interested in). But please bear with me, I am no git expert, just read the manual and try to follow it. rgds jan I. We can with a relative simple patch platform= to configure avoid 2, but 1 is going to be PITN. Also the symphony branch is missing because it was checked into svn at a non-canonic location so the git-mirror couldn't pick it up. If those branches are changed to normal, the mirror should pick it up. Yes. But I look forward to git's proper author attributions, interactive rebasing, intact individual commits after merges, nice cherry-picks, etc. I think we should have a discussion on the list. I am convinced that git offer some advantages but also some disadvantages (like branch switching) and I feel everybody should have a clear view of pro/con before we decide. +1 Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
How to distinguish whether a 32 or 64 bit AOO is installed on systems that may host both bitnesses ? (Re: switch trunk from Mac 32bit to 64bit
Congratulations for allowing AOO be compiled in 64 bit for the MacOSX! Is or will be there a possiblity to find out which version of AOO is installed, the 32 or the 64 bit version? There is at least one (mine ;) ) third party extension that may try to add an extension to AOO. As the app can only be installed in either 32 or 64 bit, the extension support for AOO should only be installed, if bitnesses between both match. So on operating systems where AOO can be installed either as 32 or as 64 bit it would be necessary to figure out (in a platform independent way) what bitness the installed AOO carries. As unoinfo seems to not carry the bitness information, is there another (portable, platform independent) way to find out what bitness the installed AOO has? TIA, ---rony P.S.: Expecting that after all PCs migrated from 32 to 64 bit, that then the migration to 128 will start, such that this remains an interesting piece of information for the times to come. On 19.12.2013 17:29, Herbert Duerr 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. - 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
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. Do we also need to update information on the download page (e.g. that we only support OSX 10.7 and up) ? rgds jan I. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: AOO is now also available as GIT (READ-ONLY).
On 19.12.2013 17:38, jan i wrote: On 19 December 2013 16:28, Herbert Duerr h...@apache.org wrote: On 19.12.2013 15:37, jan i wrote: We have anyhow to consider it the GIT branch is a practial solution, I just did a branch switch and encountered 2 problem: 1. The switch alone to 20 minutes A svn switch between two branches takes about the same time, doesn't it? Window's file access is unfortunately quite slow. On Linux or on Mac the filesystems are no bottleneck so checkouts don't take long. The difference (of course I might use git wrongly), is the in svn, the branch is stored in its directory. With git I same disk space (trunk and branches are in 1 directory) but it needs to write a lot of files. Ah, so you were not checking out trunk or branches individually but you conceptually had all of http://svn.apache.org/repos/asf/openoffice/ which contains the website, all branches and trunk. With some trickery you didn't actually check out the directories you were not interested in. So when you built the branches in their individual directories they couldn't interfere. If you like this setup with the individual directories per branch then I suggest to first do a reference clone of our git mirror: git clone --bare git://git.apache.org/openoffice.git aoo.git and then checkout each branch you are interested in, e.g. git clone --reference aoo.git --branch capstone2013 git://git.apache.org/openoffice.git mycapstone2013 You can then work on these individual git branches as you were doing with the svn branches. He, I think it boils down to what I wrote in 1). Git standard keeps trunk/branches in one directory, and for small projects its very fast to switch. Try out the setup I suggested above. There is no need to switch (and rebuild from scratch) if you like it that way. I have managed with a trix to have a git trunk in one directory and a git branch in another directory. However when I read the git manual that is not how its supposed to work. If your preferred workflow uses different directories then THAT's how its supposed to work ;-) But maybe you are using a different setup for your svn repos? Do you have one checkout per branch you are interested in? You can do the same with git of course and with git-clone's --reference option you can even share the meat of the different repositories, which is something very nice that I missed in Mercurial or now in Subversion. I have the setup: /x1/aoo/trunk /x1/aoo/branches so one big aoo directory with everything (I have asked svn to ignore the branches am not interested in). As mentioned above you can have its equivalent in git. Without the ignore-trickery you had to use ;-) But please bear with me, I am no git expert, just read the manual and try to follow it. We'll help each other on the way to a perfect workflow. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Reopening the Vietnamese Forum
Le 18/12/2013 13:05, Drew Jensen a écrit : FWIW I would close and remove the site. The real problem is lack of interest by users. The VI user activity never really was adequate to support a forum IMO. Basically, I agree. But since someone thought that there would be worth a try, I'd like to wait a bit and see he manages to revive it. Even if it doesn't seem to be the case for the moment, the forum has reopened rather recently so let's wait and see. As long as spam is under control, there is no big issue. Hagar - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: OpenOffice passwords: What are we telling users on the forums?
Top posting. For the record, a query about password topics: https://forum.openoffice.org/en/forum/search.php?keywords=passwordterms=allauthor=sc=1sf=allsr=topicssk=tsd=dst=0ch=300t=0submit=Search Indeed, we are several users advising to switch from AOO password to 3rd party password (pwd archive for example). We have seen some cases of data loss. See: - https://forum.openoffice.org/en/forum/viewtopic.php?f=7t=65258 - https://forum.openoffice.org/en/forum/viewtopic.php?f=9t=55698 - https://forum.openoffice.org/en/forum/viewtopic.php?f=7t=54816 (not much information, I agree) - https://forum.openoffice.org/en/forum/viewtopic.php?f=9t=10401 (with a fix) Other issues: - https://forum.openoffice.org/en/forum/viewtopic.php?f=6t=49537 - https://forum.openoffice.org/en/forum/viewtopic.php?f=9t=64901 - https://forum.openoffice.org/en/forum/viewtopic.php?f=9t=63279 - https://forum.openoffice.org/en/forum/viewtopic.php?f=9t=54865 I remember some other topics but couldn't find them right now. I confirm that we are talking about the file encryption and that in most cases, there is no question on the password itself Hagar Le 17/12/2013 21:44, Rob Weir a écrit : I noticed this note, which I thought was odd: http://listarchives.libreoffice.org/global/users/msg35699.html I'm hoping this is just a confusion, but we do need to be careful to avoid confusion in this area, since it can cause users to panic. The facts, as I understand them: There are two features in OpenOffice (and in LibreOffice and Microsoft Office) that users refer to when they talk about passwords: 1) Password protected encrypted documents 2) Password protected sections, cells, read-only files, etc. An encrypted document is as good as your password. We use good, high quality encryption in ODF documents by default. And we use MS Office compatible encryption, which is also good, with Office files. But in practice most users have far weaker passwords than they should. The context of a password protected file is much more vulnerable than a website password. A typical website will allow you to attempt a log in 3 or 5 times before locking you out for an hour or more. But someone who has your encrypted document can attempt to guess the password without any such restriction. They can run sophisticated programs, standalone password crackers, with GPU hardware acceleration to attempt billions of passwords. So a casual password of 6 alphanumeric characters will be quickly broken. So given the context users should be using longer, more complex passwords. Of course, that makes it more likely that they will forget the password and show up on the forums when they forget. However you look at it, document-based passwords are a 1985 solution to a problem that is better solved today in other ways. As for the protected sections, we should all know that these are honor system protection mechanisms, essentially child safety locks, and offer no real cryptographic protection. This is true in MS Office is well. The feature is there to help the user define sections that they don't want accidentally deleted, but the password protection can be trivially defeated in 30 seconds with a text editor and a copy of unzip. This is not a flaw in OpenOffice. This is not a bug. This is how the feature was designed and has been used in Microsoft Office and even 1-2-3 before then. Hopefully we're telling users something that is consistent with what I outlined above. Of course, it is quite possible that many users will not understand this and all they hear is My password can be broken so OpenOffice is bad. Regards, -Rob - 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: openoffice build issues
in python module i am getting multiple errors. Can you please help me out. I'm not a developper but Python 2.7.5 is very old. Maybe it can be upgrade to 3.3 like LibreOffice? http://python3porting.com/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Herbert, Raymond and I are in the process of rebuilding OpenOffice with the debug flags, but have run into some errors that didn't occur the first time through in the build. The current error has caused me quite a bit of problems. We are getting a link error, unrecognized symbol in /svx/source/engine3d/e3dundo.cxx. However the symbol that it is looking for is not present inside e3dundo.cxx. The symbol is ParagraphDataParagraphData::operator=(const ParagraphData) [sic] which we have located in /editeng/inc/editeng/paragraphdata.hxx and the implementation appears to in /editeng/source/outliner/paralist.cxx. There are some very odd things going on here. 1) paragraphdata.hxx is not included in paralist.cxx even though this is where the prototype is declared. 2) e3dundo.cxx doesn't seem to use the ParagraphData class at all. 3) e3dundo.cxx doesn't seem to include the libraries where these classes are used. I want to note that we first started the debug build using multiple processors (-P8) and perhaps that has caused problems in the ordering in which the libraries were compiled and linked. It is conceivable that this problem may be resolved with a complete system clean and rebuild in linear mode, but before we committed to another day of building the product, we wanted to check with you to see if this problem has occurred before, is it recognized or if there is a solution that you could recommend? We'd appreciate any help or insight you could provide. David Meffe P.S. I will be on holiday for the next two weeks and I believe Raymond will be as well so we may be out of communication. -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Wednesday, December 18, 2013 12:11 AM To: dev@openoffice.apache.org Cc: Steele, Raymond; Meffe, David K Subject: Re: EXTERNAL: Re: Building comphelper Hello David, Hello Raymond, On 17.12.2013 23:31, Steele, Raymond wrote: At long last Raymond and I have successfully gotten through the entire build script without a fault. The executable seemed to create just fine and we were able to launch soffice. We got the splash screen, then the executable started and the options window appeared and everything looked to be in order, That's a great success! but when we selected one of the document types to open, the executable crashed with the memory error: ./soffice[121]: wait: 6980: Memory fault I'm afraid we need a stack trace of this crash to understand what's going on. When the stack trace shows which libraries are involved then these libraries should be recompiled with debug infos (i.e. created with the debug=1 option for make or for build). Then replace the libs in your installation with the debug libs and get the stack trace of this crash. I don't think Raymond or I was expecting everything to work right on first launch and we were happy to see the splash screen, the executable start and the option menu appear. However, have you seen this type of memory error before or has it been seen by others? Do you have an idea what might cause this? If you single stepped through the huge amounts of code that is needed to get to there you'd see there is more than plenty of opportunity for something to go wrong ;-) My fear is that we have made too many modifications to the code in order to get the system to build correctly. We have removed, in small select areas, const as a qualifier to certain parameters to member functions because the system would not compile with these parameters declared as a const. We can provide a list of these locations that we have edited, I believe it is about 3 or 4 files that might have been edited in this way. The changes in the few source files you mentioned in your other mail are probably uncritical. And e.g. Calc isn't changed at all, so if it doesn't work either then I suspect the problem in a deeper layer. If you have any ideas, it would greatly help us out. Thanks. The stack trace of the crash when debug-enabled libraries were used would be very helpful Herbert - 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
On 12/19/13 5:58 PM, 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. Do we also need to update information on the download page (e.g. that we only support OSX 10.7 and up) ? yes, we should make this clear on the download page and in the release notes. But the new version itself will not run on versions lower 10.7 and have a version check, see http://people.apache.org/~jsc/screenshots/MacOS_version_check_AOO4.1.png And if somebody tries to start it, the error box with the related version info pops up, see again the screen shot. Juergen rgds jan I. Herbert - 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: How to distinguish whether a 32 or 64 bit AOO is installed on systems that may host both bitnesses ? (Re: switch trunk from Mac 32bit to 64bit
On 12/19/13 5:44 PM, Rony G. Flatscher (Apache) wrote: Congratulations for allowing AOO be compiled in 64 bit for the MacOSX! Is or will be there a possiblity to find out which version of AOO is installed, the 32 or the 64 bit version? There is at least one (mine ;) ) third party extension that may try to add an extension to AOO. As the app can only be installed in either 32 or 64 bit, the extension support for AOO should only be installed, if bitnesses between both match. So on operating systems where AOO can be installed either as 32 or as 64 bit it would be necessary to figure out (in a platform independent way) what bitness the installed AOO carries. As unoinfo seems to not carry the bitness information, is there another (portable, platform independent) way to find out what bitness the installed AOO has? no I think today it is not so easy to detect but it sounds like a useful enhancement. Juergen TIA, ---rony P.S.: Expecting that after all PCs migrated from 32 to 64 bit, that then the migration to 128 will start, such that this remains an interesting piece of information for the times to come. On 19.12.2013 17:29, Herbert Duerr 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. - 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
