Jesus committed a fix for this to master as: http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?id=aac47dc11beea0dda755dbf7e9fa973d367998c5 However, we need more confidence around it. There are a number of usages of these registry keys across the code (and perhaps more we are as yet unaware of) that need to be audited. In particular, as these apply to OLE2 document formats, and so on: Indeed - we need to be sure that we do not accidentally loose the ability to replace OO.o - wrt. rendering, loading and saving its embedded documents :-) Personally - I do not believe perfect co-existence will be (in the end) possible. The Windows compound document code has to have a single client that it activates to handle a component type; we simply have to fight over that association. shell/source/win32/shlxthandler/util/fileextensions.cxx: { ".odb", L".odb", "opendocument.DatabaseDocument.1" } vs. this: - Value = "opendocument.DatabaseDocument.1"; + Value = "libreoffice.DatabaseDocument.1"; setup_native/source/win32/customactions/reg4allmsdoc/reg4allmsi.cxx 'CheckExtensionInRegistry' which uses the old path cf. g grep '"OpenOffice\.org\,' setup_native/source/win32/customactions/reg4msdoc/registrar.cxx Tor reports that the reg4msdoc directory isn't built ;) filter/source/msfilter/msoleexp.cxx seems to use these names for OLE storage types: may end up in documents ... I suspect that the "opendocument." prefix may be important there (?) embedserv/source/embed/guid.cxx similarly.
Changed registry prefix values loffice, libreoffice -> LibreOffice in master: http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?id=b303988ced93a1b382e40c1faad4be84380b8d91
Win32 shell extensions updated to use the new registry file extension IDs: http://cgit.freedesktop.org/libreoffice/libs-core/commit/?id=b2db9fe070273ca251875d6540e4690695d9b2ce
Reg4allmsdoc updated to use the new registry file extension IDs: http://cgit.freedesktop.org/libreoffice/components/commit/?id=35ebcf0ac8befdbee7afa9860266327cab99ab08
New Registry File Extension IDs Substitution Table: soffice.StarWriterDocument.6 -> LibreOffice.StarWriterDocument.6 soffice.StarCalcDocument.6 -> LibreOffice.StarCalcDocument.6 soffice.StarImpressDocument.6 -> LibreOffice.StarImpressDocument.6 soffice.StarDrawDocument.6 -> LibreOffice.StarDrawDocument.6 soffice.StarMathDocument.6 -> LibreOffice.StarMathDocument.6 soffice.StarWriterTemplate.6 -> LibreOffice.StarWriterTemplate.6 soffice.StarWriterGlobalDocument.6 -> LibreOffice.StarWriterGlobalDocument.6 soffice.StarDrawTemplate.6 -> LibreOffice.StarDrawTemplate.6 soffice.StarImpressTemplate.6 -> LibreOffice.StarImpressTemplate.6 soffice.StarCalcTemplate.6 -> LibreOffice.StarCalcTemplate.6 opendocument.WriterDocument.1 -> LibreOffice.WriterDocument.1 opendocument.WriterTemplate.1 -> LibreOffice.WriterTemplate.1 opendocument.WriterGlobalDocument.1 -> LibreOffice.WriterGlobalDocument.1 opendocument.WriterWebTemplate.1 -> LibreOffice.WriterWebTemplate.1 opendocument.CalcDocument.1 -> LibreOffice.CalcDocument.1 opendocument.CalcTemplate.1 -> LibreOffice.CalcTemplate.1 opendocument.DrawDocument.1 -> LibreOffice.DrawDocument.1 opendocument.DrawTemplate.1 -> LibreOffice.DrawTemplate.1 opendocument.ImpressDocument.1 -> LibreOffice.ImpressDocument.1 opendocument.ImpressTemplate.1 -> LibreOffice.ImpressTemplate.1 opendocument.MathDocument.1 -> LibreOffice.MathDocument.1 opendocument.DatabaseDocument.1 -> LibreOffice.DatabaseDocument.1
Again - I am very concerned that we can do this without breaking documents. I attach a .doc file containing two embedded OLE2 objects provided by LibreOffice. running strings on it shows eg. opendocument.DrawDocument.1 Embedded Object opendocument.CalcDocument.1 Embedded Object jT?> mimetypeapplication/vnd.oasis.opendocument.graphicsPK Creating these documents is not -that- easy; the traditional OLE2 cut/paste-special is clearly -very- deprecated in MS Office, and/or we totally fail to launch and do our OLE2 stuff via the MS insert->object method it seems(?). Here is how to do it: Launch LibreOffice, insert->object->from file of some draw / calc files into a writer document (or any other combination thereof). Tools->Options->Load/Save->Microsoft Office - and disable the OLE2 embedded object conversion in each direction [ AFAIR this is the default for Oracle's OO.o ]. Save as .doc; load in MS Office; see that we get the WMF preview (that is easy), *but* we need to be able to edit that document data - by double clicking, so we get the in-place editing. NB. this should work on a clean install, with only the new build, an my old document (as attached).
Created attachment 42740 [details] sample .doc file created with old OO.o / LibreOffice
Created attachment 42741 [details] picture of it happening
This a build of master of yesterday evening. It includes my latest changes: http://dl.dropbox.com/u/193133/LibO_3.3.0rc2_Win_x86_install_en-US.exe
Let me add that your concerns are absolutely right. I haven't touched the OLE code yet, as it's the part of the code that requires more thinking. With the current code in master, your test case will not work. And this is what I am going to change today. The planned changes will allow the user to edit the document in either OOo or LibO depending which program was the original creator. But at the same time will create a well known incompatibility. That is: if the user created the OLE2 object with LibO will only be able to edit it if the user has LibO installed, OOo will not do it.
Hi Jesus: > But at the same time will create a well known incompatibility. That is: > if the user created the OLE2 object with LibO will only be able to edit > it if the user has LibO installed, OOo will not do it. So - the converse of this is - that he will not be able to edit documents he created in OpenOffice or Microsoft Office (cf. the above), if he has LibreOffice installed. Again - I don't think that is acceptable; and I -really- don't think we can do anything about it :-) IMHO - it would be better to: a) not rename these keys. and b) add code to arbitrate the fight over them: "I see that LibreOffice is not registered as the primary XYZ click 'OK' to make it so" - which will set the (old name) keys correctly at first launch. If we were feeling friendly, we could even "up-stream" this to share it with Oracle; which might help. IMNSHO this is the only real option here - there is a single, non-shared namespace; and there is no option but to tread on it.
All the changes have been reverted in master. So now master is exactly the same as the 3.3.x branch. In my opinion, there are a few changes only related to file associations (and not OLE2 stuff) that make sense to be made. Also I suggest to rename the exectuable files on Windows (which requires a few changes in scp2 too as we have to update the registry entries for them)
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
With 3.5.0 problem still exist?
May be it is related somehow: Bug 42661 - No associated "Alternatively Open With..." items in EXPLORER context menu available
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
I believe Jesus did get a set of fixes for this into master in the end; but wrt. the OLE2 keys there's not much we can do except fight more intelligently.
Most of the fixes are in 3.6 and this version is installable side by side with other StarOffice derivatives without any major pain. Some minor issues still exist, but they are unlikely to affect the work of a regular Windows user in any way. In my personal opinion, the work in 3.6 is already good enough to be able to claim that we play nice with other FOSS office suites and also to implement further features regarding Windows 7 and 8 integration.