Hi GetImplementationName method returns com.sun.star.comp.Writer.TextDocument rather than SwXTextDocument as before. (same for other formats of course : com.sun.star.comp.Calc.SpreadsheetDocument) Steps to reproduce: Execute : print thiscomponent.getImplementationName Platform: Windows 7/64 & Version: 5.0.0.2.0+ Build ID: d119b3d45d8075e981ca5c09e987f9445f829971 TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-0, Time: 2015-07-09_11:29:35 Locale: fr-FR (fr_FR) Also reproduced (fr-qa, fr-user) so I set status to New. I have nothing against this change but it should at least be documented in the release notes for a number of programs and extensions using this feature will not function. Regards Pierre-Yves
Changed in the following commit: commit 3099c70b11c7e5b80fe4dbe3dc99171fb38c6fc2 Author: Stephan Bergmann <sbergman@redhat.com> Date: Tue Mar 17 12:25:11 2015 +0100 Fix various XServiceInfo implementations ...to match what is recorded in the .component files Change-Id: Ie548cd37872d3b8540222201afaac73040e65c8f @Stephan: Thought you might want to comment on this change. Should we worry about it, given that people seem to use it in macros, or it's enough to just document it in the release notes? (And BTW, the old behavior is still documented at least at http://opengrok.libreoffice.org/xref/core/sw/qa/extras/README#160.)
(In reply to pierre-yves samyn from comment #0) > I have nothing against this change but it should at least be documented in > the release notes for a number of programs and extensions using this feature > will not function. Are you aware of any programs or extensions that rely on specific values being returned from getImplementationName()?
Hi (In reply to Stephan Bergmann from comment #2) > Are you aware of any programs or extensions that rely on specific values > being returned from getImplementationName()? e.g. TemplateChanger I can possibly not understand your question, but we can not list all of them of course. Their developers will have to make updates and include the test version. It is not our bug... But they need to be informed, right? Best regards Pierre-Yves
(In reply to pierre-yves samyn from comment #3) > (In reply to Stephan Bergmann from comment #2) > > Are you aware of any programs or extensions that rely on specific values > > being returned from getImplementationName()? > > e.g. TemplateChanger I do not find the (case-insensitive) string "getimplementationname" in any of the zipped files in <http://extensions.libreoffice.org/extension-center/template-changer/releases/1.2.6/template-changer-1.2.6>? > I can possibly not understand your question, but we can not list all of them > of course. Their developers will have to make updates and include the test > version. It is not our bug... But they need to be informed, right? I was not aware of any code that would rely on specific values returned from getImplementationName, that's why I asked. (It would be an error for code to rely on such specific values.)
(In reply to Stephan Bergmann from comment #4) > I do not find the (case-insensitive) string "getimplementationname" in any > of the zipped files in > <http://extensions.libreoffice.org/extension-center/template-changer/ > releases/1.2.6/template-changer-1.2.6>? It has this code inside TemplateChanger.xba: If oDoc.ImplementationName <> "SwXTextDocument" Then assignTemplateToDoc = ERR_DOC_NOT_WRITER Exit Function EndIf
(In reply to Maxim Monastirsky from comment #5) > If oDoc.ImplementationName <> "SwXTextDocument" Then > assignTemplateToDoc = ERR_DOC_NOT_WRITER > Exit Function > EndIf Stupid me. So as there's indeed external code depending on those names (as bad as that is), it might be better to redo 3099c70b11c7e5b80fe4dbe3dc99171fb38c6fc2 in the other direction, making .component files match getImplementatName() implementations.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=61a3be76c221c822b189d20e9269ec5caf1aadcc tdf#92668: Revert some implementation names, for backwards compatibility It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3b3dbb84cd0d80af230e6751303408750a7f4815&h=libreoffice-5-0 tdf#92668: Revert some implementation names, for backwards compatibility It will be available in 5.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-5-0-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=24d0bf5bc012abf6c1cb480c173055d61352d5b0&h=libreoffice-5-0-0 tdf#92668: Revert some implementation names, for backwards compatibility It will be available in 5.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.