* Update translations from branch 'master'
to d317ea9b3412438e83f716001d7fda3a62516855
- Updated Slovenian translation
Change-Id: I2edec53223e0c5c09cff8fc58265f32d6aa3da8e
...so that with Clang 15 trunk after
<2cb2cd242c>
"Change the behavior of implicit int diagnostics" the check now failed to
compile with
> configure:21471: checking alignment of long
[...]
> conftest.c:166:2: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
with consequences the same as in f6be6cd82b
"external/firebird: Missing include in configure check" (so rename the existing
configure-include.patch, as it now covers various kinds of C99 violations)
Change-Id: I64e7c13945a3ede3900cc6a84da575e35bdce953
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133994
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Delete CJK-style mnemonics for the dropdown menu of the 'New button' and lower menu of 'File > New' on macOS
Change-Id: Idd0ab671cd75151095c92b37e5b6b5e81ddae7e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133973
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
...causing
> checking for compatible POSIX regex... no
> configure: error: broken POSIX regex!
> make[1]: *** [external/openldap/ExternalProject_openldap.mk:40: workdir/ExternalProject/openldap/build] Error 1
due to
> conftest.c:88:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
with Clang 15 trunk after
<2cb2cd242c>
"Change the behavior of implicit int diagnostics"
Change-Id: I8fb70ce21a73293e20bbc5b09c133141aa9b0ca1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133995
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Like Change-Id I9d563b6ad4ed70a891c583a82331dd80db5956dc,
"android: Avoid using res ID in switch-case (FormattingController)",
but for `TollbarController`.
Change-Id: I40f23b6a91ddf0bb7e90c3b3b690fe332cd874ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133999
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Addresses this Lint warning:
> ../../src/java/org/libreoffice/SearchController.java:73: Resource IDs
> will be non-final by default in Android Gradle Plugin version 8.0, avoid
> using them in switch case statements
There's no need to explicitly set `SearchDirection.DOWN`
for `R.id.button_search_down` since it has previously been
set as default value anyway.
Change-Id: I283c00b97e1417f5dc3a48922238df7a29032137
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133998
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Adresses Lint warnings like this in FormattingController:
> ../../src/java/org/libreoffice/FormattingController.java:89: Resource
> IDs will be non-final by default in Android Gradle Plugin version 8.0,
> avoid using them in switch case statements
>
> 86
> 87 switch(button.getId()) {
> 88
> 89 case R.id.button_insertFormatListBullets:
> 90 LOKitShell.sendEvent(new LOEvent(LOEvent.UNO_COMMAND, ".uno:DefaultBullet"));
> 91 break;
Change-Id: I9d563b6ad4ed70a891c583a82331dd80db5956dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133997
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Add a button in the color palette UI
(that can be found in the bottom toolbar
under "Styles" -> "Font Color"/"Highlight Color"
when experimental editing mode is enabled) which
allows setting auto color for the font
or the highlighting/background.
This allows to unset any explicitly set color and
use the automatic color.
This is equivalent to the "Automatic"/"No fill color"
items in the font color and character highlighting
color popups in the desktop version.
Add a `boolean keepAlpha` param to
`sendFont{,Back}ColorChange` to be able
to distinguish between "auto color" and white
when -1/0xFFFFFFFF is passed as color.
See also previous commit
Change-Id I2e6512f32e671f92c8d31b2780c350dd74fb0747,
"android: Handle auto color as such", for some more
context.
Change-Id: I05182a2adbc00e64b1925ff52861a51ba8dcc21f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133996
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When no color is explicitly set for the font/background
(i.e. automatic color is used which would e.g. be black
for the font if no background color is set or white
if a black highlight color is set in Writer), the value
for the color sent in the ".uno:Color" event for the font
color and similarly for the background/highlight color
(".uno:BackgroundColor" in Calc, ".uno:CharBackColor"
in Impress, ".uno:BackColor" in Writer) is -1.
The previous handling of that special value was problematic:
1) Where handled specifically, -1 was interpreted as "black color"
rather than "auto/no color".
2) The color handled by the above-mentioned UNO events
does not contain/handle the alpha channel, while Android
does, so a conversion happens to add/remove the alpha
layer.
However, the anonymous `ColorPaletteListener`s that handle font
and background color updates in their `updateColorPickerPosition`
methods were not doing a logical or to add an alpha channel to
the LO-provided color, but *adding* 0xFF000000 instead, which is
the same for actual colors without an alpha channel set, but
the actual special value of -1 (0xFFFFFFFF) would then
be converted to 0xFEFFFFFF and no longer be treated as
special.
The way of treating -1 as black would also have the
side effect that an explicit white color (0x00FFFFFF) would
be converted to 0xFFFFFFFF, which is -1, and
would therefore be treated as black.
(So setting font color to white would result in black
being shown as font color in the font color UI in experimental
mode instead...)
In order to actually handle auto color as such, handle
the special value of -1 right in the `updateColorPickerPosition`
methods: In that case, unselect any explicitly selected color
(and set color to transparent for the buttons in the "Style"
tab of the toolbar, `font_color_picker_button`
and `font_back_color_picker_button` in `toolbar_bottom.xml`).
Also, do a logical or to add the alpha layer instead
of adding 0xFF000000.
While at it, unify the code in the two
`updateColorPickerPosition` methods a bit.
Change-Id: I2e6512f32e671f92c8d31b2780c350dd74fb0747
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133992
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In Android Viewer with experimental editing mode enabled,
doing the following resulted in black still being marked as
the current font color in the "Style" -> "Font Color" UI.
1) create a new Writer doc in the desktop version with one
paragraph that has the font color explicitly set to black
and one with "Dark Brick 2"
2) open the doc in Android Viewer with experimental mode enabled
3) tap on the first paragraph with font color explicitly set to
black
4) open the "Style" -> "Font Color" UI where the color could be
changed (layout file: `toolbar_color_picker.xml`)
-> black is marked as current font color (OK)
5) tap on the paragraph which has font color "Dark Brick 2" set
-> black is still marked as current font color (NOK)
This is because the indices of the previously set
color would just remain set if the new color
was not found in any of the palettes which contain
a set of predefined colors.
Change that to set the index for the `upperSelectedBox`
palette to 0 (i.e. switch to the first palette), and the
index of the `selectedBox` (i.e. color within the palette)
to the special value of '-1' and don't mark any palette
or color as selected in that case.
The newly introduced `ColorPickerAdapter#unselectColors`
will be used from elsewhere in a follow-up commit, so
make it public right away.
The two `ImageButton`s right in the "Style" tab
in the toolbar (i.e. `font_color_picker_button` and
`font_back_color_picker_button` in `toolbar_bottom.xml`)
remain unchanged and keep showing the actual color, since
those are not restricted to predefined colors in the
palettes.
For the case where no explicit font color is set
(i.e. use of automatic font color, e.g. black if no background
is set, but white if the background is set to black), the
value '-1' is sent from the C++ side, and no color should
be marked as selected in Android Viewer, which also works
with this change in place in general.
However, the current handling for the "automatic color" case
on Android Viewer side looks suspicious in more ways that will
be addressed in a follow-up commit.
Change-Id: I228d57ace5341bd311761f40c477441d1e511d5d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133989
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
I find
if (a == b) {
// statement 1
} else {
// statement 2
}
more straightforward than
if ( a != b) {
// statement 2
} else {
// statement 1
}
since it doesn't require logically negating twice
(else block is for `!(a != b)`) in the second form), and this
also prepares for a follow-up commit where one of the conditions
will be extended further.
Change-Id: I1d2177bdcf662994e757b626983a9f9626c66aa1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133988
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The position is already set and used in `ColorPaletteAdapter`
as its `upperSelectedBox` member, so stop doing the
double bookkeeping in both classes and retrieve it
from there instead.
Change-Id: I59896b85f5d5a0285076f61599be64638fa71121
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133987
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... and make some `final` as well.
Change-Id: Ib50ff32788edaea753cc25f119f91a93e936b2ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133986
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Addresses these suggestions shown in Android Studio:
* "Explicit type argument String can be replaced with <>"
* "Explicit type argument String, ArrayList<String> can be replaced with <>"
Change-Id: Ibc78364cf5b246d8c1e1d32d755c3e8dcf0e32aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133985
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
There is already a loop just before this one,
so just move that assignment there as well.
Change-Id: Ie93a0275c0940b7932973264352bad64d0489b03
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133984
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... instead of creating the color from the RGB
values manually.
Change-Id: I2058de553e2e744440e7d856ca9bfaf5f9041b49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133983
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
a problem since...
commit e9c50fbbc3
Date: Sat Apr 2 15:49:32 2022 +0300
tdf#103954: Z compressed graphic formats support for EMF/WMF
which added an unconditional seek to 0 of the stream which isn't
desirable when done on the original stream which is deliberately
seeked to the start of the graphic data, seeking to 0 just skips
back to the start of the enclosing file, e.g. a word document stream.
Presumably this should just happen in the case of the replacement
decompressed stream.
Change-Id: Ifb67fb265c70d5728a74dc3499f275eb5d69ddbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133991
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
...as mnPoints is the size of mxPointAry (see also
323df76698 "Revert 'tdf#147919 PPTX export: fix
curved and bent connector shape'")
Change-Id: I10b9c6bd25bc88754d2d52e851c3871621b0d517
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133980
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
skip the cost of constructing a SimpleIOErrorRequest in the common case
Change-Id: Ib0a8989a9ffa76e6b71f984e0f32be94ec5cb8ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133959
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
which speeds it up a little, because WeakReferences are a little slow
Change-Id: I76226b180ae4e11c4beb9e2f4ae12b05f980dcad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133960
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
shaves 5% off the load time for me
Change-Id: Ia0ed8caa9300bfe5bcf71cfe844b8c4fdaf0fef6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133962
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
During the normal spell-checking in Calc, the user may change the
language on the string segment with a spelling error, which is supposed
to be applied back to that segment in the cell, but was not. This change
should fix it.
In case the new language is applied to the entire cell string, we will
set the new lanuage to the cell as a cell attribute and keep the string
as a simple string. Otherwise, the new language gets applied to the
edit engine string.
This commit also changes the return value of EditEngine::GetLanguage()
to include the string span information in addition to the language
value.
Change-Id: I713ec7aefe571f721321cd8ea687f616ab4dd61a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133966
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
