/source/sv/scp2/

Age	Commit message (Collapse)	Author
2022-06-02	clang-tidy modernize-pass-by-value in framework	Noel Grandin
	Change-Id: I024653154c51389bb27f3e94b422ff7fc1c9b46b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135296 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-30	framework: fix crash on Writer startup when using --enable-ext-wiki-publisher	Miklos Vajna
	As reported by Julien, once the mediawiki extension is installed, the xHandler in framework::DispatchProvider::implts_searchProtocolHandler() points to an UNO component implemented in Java, and we crash in dynamic_cast<>(), at least on Linux with gcc 7.5 and libstdc++. This dynamic_cast<>() call was added in commit c0fa456436947a5c167c652d19a884064b43c03d (tdf#149261 sdext: fix crash on starting the presenter console for the 2nd time, 2022-05-26), to allow the presenter console to opt out from protocol handler caching. It was expected that the proxy object created for a Java UNO component would simply return nullptr when we try to dynamic_cast<>() it down to a C++ interface. Fix the problem by moving the interface to an UNO one: this side-steps the dynamic_cast<>() crash at the price of introducing an UNO interface, which is not meant to be part of the public UNO API (but at least it's not published). It may still make sense to improve the bridges/ code at some stage to not crash in dynamic_cast<>() on generated Java proxy objects. Change-Id: Iaac44515339e0dc15dddc3be45ef7dee7331e47a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135114 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2022-05-26	tdf#149261 sdext: fix crash on starting the presenter console for the 2nd time	Miklos Vajna
	This started with commit 3f768cddd28a2f04eb1ffa30bed4474deb6fbfc4 (framework: avoid re-creating protocol handler instances all the time, 2022-05-02). In case there are 2 monitors, then one monitor shows the slideshow, the other shows the presenter console. The presenter console's protocol handler in sdext::presenter::PresenterProtocolHandler::Dispatch::Dispatch() has mpPresenterController->GetWindowManager() as an empty reference on the 2nd time the presentation starts. The above commit started to cache protocol handler instances at a frame level for performance reasons, and this is meant to be safe in general, but the presenter console's window manager is re-created between slideshow runs, so it depends on framework/ code to re-create the protocol handler all the time, which is problematic here. Fix the problem by introducing a framework::CacheInfo interface that allows protocol handler implementations to signal if they want to avoid being cached. This should be good enough for now, but if later it turns out that there are too many broken protocol handlers out there, then we can consider flipping the default and only cache handlers which explicitly opt in for this behavior. This is not done in this commit. Change-Id: Ic159813b1b339540bc8c4e780c4d6d7d2d4d2445 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135020 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-08-18	loplugin:passstuffbyref	Noel Grandin
	Change-Id: I4f01eb3842ef198f02af274f54afb2760c820a4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120655 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-30	osl::Mutex->std::mutex in DispatchHelper	Noel Grandin
	Change-Id: I6443f604f7f5cacc4b3d67bb6dab07706c82a9a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119700 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-07	framework: create instances with uno constructors	Noel Grandin
	See tdf#74608 for motivation Change-Id: I8679b50395d11cb2d807d52526d803df9b0606b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98294 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-04	reduce number of framework libraries	Noel Grandin
	Change-Id: If2bf85301eb1523a636d031f6e5a9f78cb1ee06b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97871 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-23	make more classes private in mergedlibs mode	Noel Grandin
	Change-Id: I486922d0652f26fa7ee56f5fe308e19fe5ff137e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90856 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-29	loplugin:finalclasses filter..framework	Noel Grandin
	Change-Id: Ic4d0a2946c925035d60defc4d25caea05535adbc Reviewed-on: https://gerrit.libreoffice.org/81654 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-07-10	Fix typo	Andrea Gelmini
	Change-Id: Ifec4056dff92422b06c8ef6ffe85bec89329ec90 Reviewed-on: https://gerrit.libreoffice.org/75324 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-03-01	clang-format DispatchHelper	Samuel Mehrbrodt
	To reduce excessive whitespace in function definitons Change-Id: I8dbf58e5ba53ddcf6c5a8e212636c1306584aa2e Reviewed-on: https://gerrit.libreoffice.org/68533 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2019-02-19	tdf#42949 Fix IWYU warnings in include/framework/	Gabor Kelemen
	Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ia9616f644a68ec6da22e646ba0d919a3489a9481 Reviewed-on: https://gerrit.libreoffice.org/67745 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2017-12-14	No need to keep these whitelisted functions decorated with SAL_CALL	Stephan Bergmann
	The only effect SAL_CALL effectively has on LO-internal code is to change non- static member functions from __thiscall to __cdecl in MSVC (where all other functions are __cdecl by default, anyway). (For 3rd-party code, it could be argued that SAL_CALL is useful on function declarations in the URE stable interface other than non-static member functions, too, in case 3rd-party code uses a compiler switch to change the default calling convention to something other than __cdecl. But loplugin:salcall exempts the URE stable interface, anyway.) One could argue that SAL_CALL, even if today it effectively only affects non- static member functions in MSVC, could be extended in the future to affect more functions on more platforms. However, the current code would already not support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c "loplugin:salcall fix functions" changed FrameControl_createInstance in UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even though its address (in ctl_component_getFacrory, in the same file) is passed to cppuhelper::createSingleFactory as an argument of type cppu::ComponentInstantiation, which is a pointer to SAL_CALL function. Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6 Reviewed-on: https://gerrit.libreoffice.org/46436 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-13	Make loplugin:salcall look into macros too	Stephan Bergmann
	"Indirect" calls to isSallCallFunction (for canonic and overridden FunctionDecls) already needed to handle many cases of FunctionDecls spanning macros, so it isn't that much more work to make that also work for cases called directly from VisitFunctionDecl. Change-Id: I529f148c8872b86aa1ef082c6cb73db8ab1866e7 Reviewed-on: https://gerrit.libreoffice.org/46367 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-05	loplugin:salcall fix non-virtual methods	Noel Grandin
	first, since those are safer to change than virtual methods Change-Id: Ie3b624019d75ee2b793cee33b3c5f64e994e8bfe Reviewed-on: https://gerrit.libreoffice.org/45798 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-01-26	Remove dynamic exception specifications	Stephan Bergmann
	...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html> "Dynamic Exception Specifications" for details. Most changes have been done automatically by the rewriting loplugin:dynexcspec (after enabling the rewriting mode, to be committed shortly). The way it only removes exception specs from declarations if it also sees a definition, it identified some dead declarations-w/o-definitions (that have been removed manually) and some cases where a definition appeared in multiple include files (which have also been cleaned up manually). There's also been cases of macro paramters (that were used to abstract over exception specs) that have become unused now (and been removed). Furthermore, some code needed to be cleaned up manually (avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no configurations available that would actually build that code. Missing @throws documentation has not been applied in such manual clean-up. Change-Id: I3408691256c9b0c12bc5332de976743626e13960 Reviewed-on: https://gerrit.libreoffice.org/33574 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-01-19	New loplugin:dynexcspec: Add @throws documentation, framework	Stephan Bergmann
	Change-Id: I19a4517449be3defe97fe0d78dd1a16b08b79247
2016-10-03	Fix typos	Andrea Gelmini
	Change-Id: I7000efdb7276053c16de992fa8f9a4e614ecb3e2 Reviewed-on: https://gerrit.libreoffice.org/29434 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-09-13	loplugin:override: No more need for the "MSVC dtor override" workaround	Stephan Bergmann
	The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark overriding destructors as 'virtual'" appears to no longer be a problem with MSVC 2013. (The little change in the rewriting code of compilerplugins/clang/override.cxx was necessary to prevent an endless loop when adding "override" to OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager(); in chart2/source/inc/LifeTime.hxx, getting stuck in the leading OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.) Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
2016-06-08	tdf#99815 use XNotifyingDispatch in sfx2	Juergen Funk
	- move DispatchHelper somewhere public - use it from generic dispatcher call sites in sfx2 - return result of dispatcher calls (conveyed via XDispatchResultListener) to calling code, instead of faking it Change-Id: Ie8041133e99dd99e45819f98798829b96532b9e6 Reviewed-on: https://gerrit.libreoffice.org/24953 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>