Converted them as usual service implementations.
Otherwise - if static singletons are used -
it does not show menu for some reason.
Change-Id: I0673d0bfbba268728a3fa676f2af95aa6c74bbb2
To replace single-instance com.sun.star.util.PathSettings service,
incorrectly converted in 89b0017b22889af6a8afe28b94c06e7095dc8c6f
Keeping util::PathSettings::create in
sc/source/ui/vba/vbaapplication.cxx because for some reason
util::thePathSettings::get does not work in sc_macros_test
while testing sc/qa/extras/testdocuments/Ranges.xls.
Change-Id: I75b68ae56ac5b58f72416070dba100ab3ab70fe8
it's unused internally as far as I can see and has very incomplete (and surely
some wrong values) from some sort of mid 90s Euro-centric worldview
Change-Id: Ibce9e8b76545791ab59b9e11c6ff6e1f33afcb3c
ResMgr::GetLang() has been deprecated for a long time now. It is used
by only one function,
SubstitutePathVariables::SetPredefinedPathVariables() in the framework
module. I have therefore removed it from ResMgr and placed it as a
function in framework/source/services/substitutepathvars.cxx where it
is actually used.
Change-Id: I5f0d8f701aa45f8653020affeff6339f8fc9bc0e
Reviewed-on: https://gerrit.libreoffice.org/7791
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
com.sun.star.frame.thePopupMenuControllerFactory
com.sun.star.frame.theStatusbarControllerFactory
com.sun.star.frame.theToolbarControllerFactory
To replace their single-instance service variants.
Change-Id: I00586d0d61e63f9482cb659071e88aa9cf02d5b5
To replace com.sun.star.frame.AutoRecovery single-instance service,
incorrectly converted in 279859fdbc40f68d8f1649fa5b928d9de49e8d9e
Unfortunately needs a lot of changes in autorecovery.cxx.
Change-Id: Iba5188dffea3e03803236f23e0b3f343746ace90
To replace com.sun.star.task.JobExecutor single-instance service,
incorrectly converted in 748aa84e9808ad31c6ff6b71459525c82de10e58
[including changes by Stephan Bergmann <sbergman@redhat.com>]
Change-Id: I4cea2c63a20b5b22f6e1f822fb35fcc4d0397687
Reviewed-on: https://gerrit.libreoffice.org/7609
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
This is much better approach compared to the callback function, as it allows
passing arguments to the c++ constructor directly, while still allowing some
additional initialization after having acquired the instance.
Change-Id: I5a0f981915dd58f1522ee6054e53a3550b29d624
Many of the initalizations (in eg. framework) have to be done on an
acquire()'d object, so instead of doing the initialization directly, return
the initialization member function back to the createInstance() /
createInstanceWithContext() / ... and perform the initialization there.
As a sideeffect, I belive the calling initialize() from servicemanager is not
that much a hack any more - whoever converts the implementation to be
constructor-base has the choice to provide the callback, or still initialize
through XInitialization, where the callback is preferred by servicemanager
when it exists.
Change-Id: I8a87b75c54c1441ca0f184967d31ff4902fc4081
3af99e4d59d89c343965a928681a30f36b1007d2 "convert equalsAsciiL calls to
startsWith calls" should rather have converted to oprator ==.
Change-Id: Id4a8836c5d6d570e54661c40be7214632e202b21
