Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I56e4b5a44143ea15660cfa293e156036952dfe8f
Reviewed-on: https://gerrit.libreoffice.org/84030
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
This can happen because lcl_SelectAppIconPixmap() temporarily disables
OpenGL, but in case an icon to be loaded is already cached(?), the bitmap
variant may be OpenGL. Happens when launching LO in OpenGL mode
with the X11 gen backend, and then selecting Writer in the start screen.
Change-Id: I65110dee79769c430eaa8a2cf3dc11119ab02520
Reviewed-on: https://gerrit.libreoffice.org/84246
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The common usage pattern should be having one source file per each
instruction set and then one source file compiled with neutral flags
that dispatches to the relevant code based on runtime checks.
Which means that there can't be any one "correct" flag, otherwise
all files would get compiled e.g. with SSE4.2 but then CPUs capable
only of SSE2 would crash running that code.
Change-Id: I362bf66f672dae4588a48effe3bcd30c34ea75b3
Reviewed-on: https://gerrit.libreoffice.org/84227
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
It had curiously been added as nillable (by default) alongside other properties
that were added as non-nillable with ef809ce948
"More work on the new OpenCL options", but with a non-nil default value, and no
code sets a nil value, and ScModelObj::getFormulaCellNumberLimit, which reads
its value and expects it to be non-nil, would cause UB if it was nil.
So make it non-nillable and thereby simplify the code handling it. (Similar to
how e8bb827571 "Fixed cppheader.xsl nillable
treatment" retrofitted lots of existing properties to be non-nillable in the
past.)
Change-Id: I60ac95025f363e346f3102ef80f38d00862e6e9a
Reviewed-on: https://gerrit.libreoffice.org/84248
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
When changing the view, some components are disabled
and re-enabled. This triggers a flood of invalidations
that then result in rendering requests. For each rendering
the view is set, which triggers more invalidations.
The Sidebar suffers from this, and it causes cpu pegging.
This fix prevents this issue by disabling all callbacks
during setView.
Change-Id: If6b93b2ab31f568a0761f15d945a43de1bc2d4d0
Reviewed-on: https://gerrit.libreoffice.org/84184
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/84226
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
follow-on fixup of: 35d6c6ffc9 which ended
up not removing the duplicated conversion logic it should have.
Change-Id: I28ef0180749f6356ec456b4f0b1eef1b474fd6c9
Reviewed-on: https://gerrit.libreoffice.org/84284
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Don't duplicate this on the ITiledRenderable interface, which is not a
per-view construct, this just confuses everything.
Store & restore the zoom level before/after rendering a tile -
unfortunately this is not done by the most optimal view yet.
Change-Id: I1f7dfaa353333f45c5601d49a9bca784d34fb81a
Reviewed-on: https://gerrit.libreoffice.org/84281
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Normally layout flow is set to vertical to denote TBRL, and then
optionally there is a layout flow alt to denote BTLR, but the bugdoc
shows that the first may be missing.
So map to BTLR even in case only the alt layout flow is found in the
file.
Change-Id: I06fce738fca9aedc0de90ccebda3a24e99425326
Reviewed-on: https://gerrit.libreoffice.org/84275
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
The open_004 unit test fails on Windows with E_NOENT. I think the
assert is correct, and it's better change the ERROR_DIRECTORY
mapping, as FindFirstFileW returns ERROR_PATH_NOT_FOUND, if the
path doesn't exists at all.
The description of that error code in the MS API docs is "The
directory name is invalid.". And obviously there is no way to
tell, if this is actually a better mapping.
Change-Id: Id122ce39e90f3562e70c96a06752e5b32ed55b41
Reviewed-on: https://gerrit.libreoffice.org/84070
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This just disables open::open_004 test on Windows, as this returns
E_NOENT on Windows, but I think the assert is correct. There is
also test-getsystempathfromfileurl.cxx, which seems to overlap?
The test now uses osl::FileBase::getTempDirURL to find the system
temporary directory, insted of hardcoded defaults.
This also includes reverts the following commits:
* "remove unused Exist from oslCheckMode enum"
commit 4ca9e8fa3a.
* "CppunitTest_sal_osl_file fails on Windows"
commit 4603028bc4
Change-Id: Ib7fc4c13f8159a240d4e20c26f61d84204e4261b
Reviewed-on: https://gerrit.libreoffice.org/83901
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
lok clients can request to complete a function name partially typed in
the formula input box.
Change-Id: I8771fd4d2a7f79c20138d9183162da23a92f2ba4
Reviewed-on: https://gerrit.libreoffice.org/83984
Reviewed-by: Marco Cecchetti <marco.cecchetti@collabora.com>
Tested-by: Marco Cecchetti <marco.cecchetti@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/84258
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Only sending as other formats should be disabled in this case
Change-Id: I985d43ba314a1bda16dab33897d212ad27d3d115
Reviewed-on: https://gerrit.libreoffice.org/84240
Tested-by: Jenkins
Reviewed-by: Serge Krot (CIB) <Serge.Krot@cib.de>
"Use initializer list instead of using several inserts (sc/vba)"
I had forgotten to remove the initial commented code
Change-Id: I6b70966e7a446addbfc4d64464047c167efcea71
Reviewed-on: https://gerrit.libreoffice.org/84264
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Show and manage the default Writer print options in the "Tools" ->
"Options" -> "LibreOfficeDev Writer" -> "Print" dialog and don't
mix in the document-specific values of the currently opened
document, as this is rather confusing as described in tdf#47583.
There is a separate dialog to manage the settings for the currently
opened document available via "File" -> "Printer Settings" -> "Options".
At a quick glance, this also matches the behaviour for Calc, which
doesn't mix in the current doc's settings either.
This handles the case for the Writer-specific print options.
For a more general approach on whether and how document-specific
options should be handled in the "Tools" -> "Options" dialog at all,
there are already tdf#43786 ("Intransparent Use of Options") and
tdf#105751 ("Separate document saved options from global options in
Options dialog").
Side note: The previous implementation also wasn't synchronizing the
settings both ways. Changes made in the "File" -> "Printer Settings" ->
"Options" dialog did show up in the "Tools" -> "Options" ->
"LibreOfficeDev Writer" -> "Print" dialog at once, but not the other
way around.
The reason is that Writer-specific print settings are currently managed
in two places in DocumentDeviceManager:
(1) its SwPrintData, accessible via
'DocumentDeviceManager::{g,s}etPrintData'
(2) the print data set in its 'SfxPrinter*'
('DocumentDeviceManager::{g,s}etPrinter')
The "File" -> "Printer Settings" -> "Options" dialog uses the settings
from the SfxPrinter. So, to make synchronization work both ways with the
previous implementation, the changes made in the "Tools" -> "Options" dialog
would also have to be applied for (2), not just (1), e.g. this way:
diff --git a/sw/source/uibase/app/appopt.cxx b/sw/source/uibase/app/appopt.cxx
index 9c7e24592014..83bae7eb71b9 100644
--- a/sw/source/uibase/app/appopt.cxx
+++ b/sw/source/uibase/app/appopt.cxx
@@ -371,8 +371,15 @@ void SwModule::ApplyItemSet( sal_uInt16 nId, const SfxItemSet& rSet )
const SwAddPrinterItem* pAddPrinterAttr = static_cast<const SwAddPrinterItem*>(pItem);
*pOpt = *pAddPrinterAttr;
- if(pAppView)
+ if(pAppView) {
pAppView->GetWrtShell().getIDocumentDeviceAccess().setPrintData( *pOpt );
+ SfxPrinter* pDocPrinter = pAppView->GetWrtShell().getIDocumentDeviceAccess().getPrinter(false);
+ if (pDocPrinter) {
+ SfxItemSet aOptions(pDocPrinter->GetOptions());
+ aOptions.Put(*pAddPrinterAttr);
+ pDocPrinter->SetOptions(aOptions);
+ }
+ }
}
}
(Maybe that should be consolidated at some point in time...)
Change-Id: I74961f4d8947e200b415e6e32e128a0ce3d317f5
Reviewed-on: https://gerrit.libreoffice.org/84212
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Similarly to commit fb1b461208 replace
new instances of boost/property_tree/ptree.hpp with forward declaration
only header, as suggested by IWYU
This reduces includebloat from 28.5G to 22.6G and cold clean build time from
real 68m54,192s
user 947m28,508s
to
real 62m50,689s
user 861m33,131s
on my machine.
Change-Id: I5530f1b4b1a46d9159c752ad5af9a408215baf40
Reviewed-on: https://gerrit.libreoffice.org/84175
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
... otherwise it assumes that only part of first string to the right of the
unchanged string part needs redrawing (which would be to the right of the
control itself)
Change-Id: I2833c1eb2026041b11d0b72431b164d2ee3befef
Reviewed-on: https://gerrit.libreoffice.org/84207
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Also drop a duplicated blacklist rule found with:
grep :$ sw/IwyuFilter_sw.yaml | sort | uniq -cd
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ied72f3f086ed4c1eb7ff4bcdbcf8aee73ddd4f7c
Reviewed-on: https://gerrit.libreoffice.org/83250
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Otherwise it is not found when the the fontconfig's ./configure is
running, which leads to linking failure during the fontconfig's
./configure time, which leads to an undefined HAVE_FT_GET_NEXT_CHAR
which leads to not using the actual FT_Get_Next_Char, but instead some
dummy code that leads to an infinite loop on the app startup; huh.
Change-Id: I40b7a403fbe75582bb98f15f1afe7a4050fd13aa
Reviewed-on: https://gerrit.libreoffice.org/83922
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit 94eb590787)
Reviewed-on: https://gerrit.libreoffice.org/84190
Tested-by: Jenkins
inside a growing text-frame after doing recalc of positions of
other frames (visually above current) in the tree. Otherwise
the as-char anchored objects gets wrong reference (base) position
(more accurately the base Y position) and hence get displayed at
wrong vertical positions (in case of the bug document, it goes
out of the page area).
Some notes about the bug:
Above mentioned problem is visible (at least) when you have a frame
anchored to the bottom of the page with auto-height and it contains
one or more <text:p> with at least one of them having a draw object
like a shape or math formula with 'as-char' anchoring. Only the
draw object in the last <text:p> is affected by the bug possibly
because this text-frame is the cause of growth of the parent (upper)
frame.
Change-Id: If968c8c00aa57d26b1000e3250b352b24df47cf6
Reviewed-on: https://gerrit.libreoffice.org/83603
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
No need for this when we have a compile-time distinction now anyway.
Change-Id: Ic86c8cce38a86635ea3efb4229c08f63059c9ee6
Reviewed-on: https://gerrit.libreoffice.org/83719
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jenkins
These are obsoleted in LibreOffice 6.5 by tdf#118947's
commit 6bced3c6a1
Both of these hacks were backported to 6.4, but
I have no intention of backporting my patch.
Change-Id: Ie639b9d55d90d25b58e140fba443fce98f2d7ba1
Reviewed-on: https://gerrit.libreoffice.org/84125
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
