* Sort presentations options, put similiar options next to each other.
* Move non-document option (Navigation bar) to "Display" area.
Also improve wording a little bit for more clarity
Change-Id: I18de6b95ea26033ef78709845db40e428a1d6c84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158831
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
not "sal_uInt16"
See "aModelPropertyInfoMap" var in starmath/source/unomodel.cxx
It fixes this message when loading https://bugs.documentfoundation.org/attachment.cgi?id=55799
warn:legacy.osl:19853:19853:xmloff/source/core/SettingsExportHelper.cxx:176: this type is not implemented now
Change-Id: I18779b122555681f7544e64745c8074775e27277
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158952
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
- in LOK case toolbars in core doesn't make any difference
- SfxNotebookBar::IsActive which reads config
makes doc_setView slower, avoid it in LOK case then
- it was used for hiding contextual toolbars
- introduced in commit 9bc1ffa215
tdf#125040 Make single mode toolbar context aware
Signed-off-by: Szymon Kłos <szymon.klos@collabora.com>
Change-Id: I63de48faf2f7e7f30f8b509455061ac20a788f8a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158939
Tested-by: Jenkins
commit 5bd2931b57
tdf#102063 Notebookbar wont appear on launch
introduced some Query hack to SfxDispatcher::Update_Impl what
causes many updates on lots of different actions.
It breaks multi-view state of notebookbar in LOK case,
so don't do that. It should be reviewed for regular case too.
Change-Id: I8f26bddc6cff991c56a1172893d83b90fb225acd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158937
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
This fixes regression from commit db5a78c8ab
lok: notebookbar: don't recreate toolbars too often
When we had 2 sessions with notebookbar and one of them switched
to compact mode - other session's notebookbar didn't work.
Before previous change we recreated notebookbar and its welded wrapper
on every StateMethod call for LOK case. So when it become destroyed
we made it working again. But now we need to introduce better management
and not rely on single instence we get from SystemWindow.
Also it's bad idea to rely 100% on SfxNotebookBar::IsActive in LOK
case as when other view will turn notebookbar off, but QueryState
will be trigerred in our session - we will think that it should be
destroyed (it reads config state which is shared between views).
So trust only "true" value (it happens after calling SID_TOOLBAR_MODE),
but destroy notebookbar only after explicit call of
SfxNotebookBar::CloseMethod. It seems to have good result when tested
with multiple views in Online. Maybe we can track Notebookbar state
per view later to make things simpler in LOK case.
Change-Id: Ie739c6441ca05884b0ef20bff23751467706b562
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158936
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Instead of hiding it in the general options dialog.
As written in https://bugs.documentfoundation.org/show_bug.cgi?id=157788#c4
"The options in Slide Show Settings should all apply to the workstation";
the options which are saved per user/workstation and not per document, should not be moved
away from that dialog.
Instead the other options should also be saved per user/workstation.
Change-Id: I720c949f08877abb8ef8f94dbcfa6c85f349631d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158808
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
After 8c39af455c
"uitest oneprocess mode: default to this and clean up one test"
Change-Id: I3da187055cc8ac239d6a4592f3050440630e051c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158654
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
After 8c39af455c
"uitest oneprocess mode: default to this and clean up one test"
Change-Id: Ib6e0fc3de2997beebc650253ae3ea19a3314ae09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158844
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Uses NSLevelIndicator to render LevelBar control on macOS.
Closely follows the existing implementation for ControlType::Progress
Change-Id: Ibd38e172b8b6297e6322cfe9d5a1b0a6ef0f0656
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158504
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
Introduces new configuration options PasswordPolicy and
PasswordPolicyErrorMessage.
PasswordPolicy takes a regular expression. When set, it only
accepts passwords that match that regular expression.
PasswordPolicyErrorMessage is the label displayed when the
password does not meet the PasswordPolicy.
In the ideal case, it should contain an explainer of the
PasswordPolicy, so the user is aware of the requirements.
Save with password dialog had maximum password length enforcing
bits depending on the requirements of the saved file format.
These are still applicable in combination with the password
policy.
Also introduces a visual password meter under the password
entries. If the password policy isn't satisfied the password
strength meter is capped at 70%.
The entropy bits to password quality is taken as a linear range.
Where the range of [0, 112] entropy bits is mapped to percentage
[0, 100]. Entropy bits ≥ 112 are mapped to 100% since, according
to KeePass' info page, ≥ 112 entropy bits correspond to a strong
password: <https://keepass.info/help/kb/pw_quality_est.html>
Change-Id: I2e70adacf271916661219f702dfc217292a1b59f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158453
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
...inspired by d4f4a40186 "This function takes a
string view - no need in OUString literal", but this found no further cases
Change-Id: I1429950afdb6fff8ed1d28f5fbb4c445fb6bfb12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158954
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The configure line can leak data from the building machine (path
names, level of parallelism etc), which leads to non-reproducible
build results.
Change-Id: I042afc3d7bad19e8e274147be2a9eb0abcf5436e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158871
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Even taking the current year from the build system makes a build
non-reproducible (if you run it again the next year).
Change-Id: I4a2ef0fe997c20d1c8ec954378f46adb5aad04df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158870
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
No need to write this legacy int16, that we ignore on read anyway.
Change-Id: I5ee071aa0562b8e2718a1a83dffc543c9a104360
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158942
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
with high parallelism there's a high risk of running into random
failures when calling WiLangId.vbs via cscript.
The limiter doesn't use make's jobserver since it is too easy to
deadlock the build since all jobs are started at once, consuming all
slots, but in addition all wait for an additional slot that never is
made available because all jobs are blocked waiting....
All jobs being started at once and all jobs getting started from that
point on getting put under the limiter's control makes this simple
approach with separate grab/release calls possible. If they were spread
out the semaphore wouldn't be available (gets closed/removed as soon as
nothing waits for it anymore)
Change-Id: I345f2904a1d7e8989720722415fb51282ab3b05b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158886
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
generated location is kept to not have further changes in existing
scripts using those files.
Change-Id: Ia14864bd6f9c69e2c77d39806e733f50155d12b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158791
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
So my strategy here is to assume that ProcessAndBlurAlphaMask
was doing the right thing before
commit 81994cb2b8
Date: Fri Apr 16 20:33:10 2021 +0200
Convert internal vcl bitmap formats transparency->alpha (II)
but the subsequent naiving changing of its logic undermines it
because of some subtle interaction.
So take the brute force approach of reverting most of the code
to its prior state (i.e. working in the transparency domain),
and doing an Invert() before and after the original code.
This seems to fix all of the test files I have on hand
for this situation for both Skia and non-Skia cases.
Change-Id: If4c4d4c5351a4ec55897bed96b57d28eda88f5dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158793
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@neooffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Bring some C++20 goodness to LOK code: avoid lots of small memory
allocations when constructing OUString from ASCII char arrays;
use string lengths known at compile and run time; use safer and
cleaner syntax.
Change-Id: Ia59ed3c8d8ce521880bb8d70b69a64b2d3e73c14
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158927
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Return type of GetColumnFormat() is changed to sal_uInt32. All the
values from the function calls inside GetCloumnFormat() which were
involved in the return value seem to be positive right now.
Change-Id: Id19b2982d8372e10fee5fc0fd4233576076ec3df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155680
Tested-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
The function getLength() returns a value as sal_Int32, which is then
assigned to the variable nLinks.
Change-Id: I44d626e2a26e3d9eb15b0884500f0dfddff12e9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157755
Tested-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
Delaying flushing until the dispatch level returns to zero causes
scrolling via the scrollwheel or mouse drag to appear laggy and
jerky.
Change-Id: Ib70e7766435baa765dd0d1d704ba2fac87f7fccc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158853
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@neooffice.org>
I can't explain why inverting using Skia causes this bug on
macOS but not other platforms. My guess is that Skia on macOS
is sharing some data when different SkiaSalBitmap instances
are created from the same OutputDevice. So, mark this
SkiaSalBitmap instance's image as immutable so that successive
inversions are done with buffered bitmap data instead of Skia.
Change-Id: I8acf90561c48edba14a5f43d16f375f15f25820c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158880
Reviewed-by: Patrick Luby <plubius@neooffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
<https://lists.freedesktop.org/archives/libreoffice/2023-November/091151.html>
"CppunitTest_stoc_uriproc failed on Windows" reports that
translateToExternal("file:///abc/%feef") produces an empty string (indicating
failure) instead of "file:///abc/%FEef" (as expected in
stoc/test/uriproc/test_uriproc.cxx) when osl_getThreadTextEncoding() is Shift
JIS.
This was due to how the call to rtl::Uri::encode in
Translator::translateToExternal (in
stoc/source/uriproc/ExternalUriReferenceTranslator.cxx) behaved: It internally
interpreted its input "%FE" as the single-byte Shift JIS character 0xFE. Which
gets mapped to U+2122 as an extension (see "APPLE additions over SJIS, we
convert this like Apple, because I think, this gives better result, then [sic]
we take a replacement char" in sal/textenc/tcvtjp6.tab) in readUcs4, but which
in turn doesn't get mapped back to any Shift JIS character in writeEscapeChar.
Translator::translateToExternal is the only user of
rtl_UriEncodeStrictKeepEscapes, as introduced by
6ff5d3341d "INTEGRATION: CWS c07v013_SRC680
(1.4.40); FILE MERGED: 2007/06/21 13:00:56 sb 1.4.40.1: #b6550116# Made
XExternalUriReferenceTranslator.translateToExternal more robust when the input
URL contains spurious non--UTF-8 octets like %FE (which are now copied verbatim,
instead of signalling error)."
To make the claim true that such "spurious non--UTF-8 octets like %FE" are
always "copied verbatim", regardless of text encoding being used, repurpose
rtl_UriEncodeStrictKeepEscapes to always treat any escape sequences that are
present as (potentially broken) UTF-8.
Change-Id: I0fa0b14d3e3d44e4b5514e1b73c84c407a947ce9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158888
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
