We require at least GCC 7.0.0 anyway, per README.md
Change-Id: Ib974690ef4e4a1861a43f33157fde9f4bb3ac8ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134080
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...and apparently doesn't need to, even though that dependency got added with
6ffdc88e79 "Simplify Sequence iterations in
shell..svgio"
Change-Id: I7cb67dc48d11e426d5d5f7912eca13e25a32dbc5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134079
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...and fail loudly if writing the file fails for any reason
Change-Id: I1e6d2e3da4d2ef643f4d27067845184dbf2e40a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134076
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...and apparently doesn't need to, even though that dependency got added with
6af2e7d21c "use more
comphelper::OInterfaceContainerHelper2"
Change-Id: I74a4d04be9a37291bc37d908173381eb341b6df4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134077
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit 59059d00c2, as it effectively
did nothing, as rvalues can bind to `const &` just fine.
<https://gerrit.libreoffice.org/c/core/+/133747> "Acutally do prevent using
O[U]String::subView on temporaties" would have fixed that, but (a) it didn't
find any actual mis-uses and (b) rather would have required a handful of
legitimate cases to be dressed up with o3tl::temporary now, so is arguably not
worth it.
Change-Id: I923d0db2646dc8ea66d1b2a8b709ee2cd7a60ed4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134058
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The logic is that in case there is no selection, we insert a placeholder
like "type here", but if there is a selection, that can be a custom
placeholder.
Without this fix, we would hit an assertion failure on inserting content
control when there is a selection, as the placeholder is empty and
operator[](0) is not allowed for empty OUStrings.
Change-Id: I8370b8d74415faf0e76dccb574aa29bea1947bb8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134041
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Without this, the implicitly created constructor is exported by MSVC
for the DLLPUBLIC class, and requires that VirtualDevice is defined,
resulting in this error in PCH-disabled builds:
[build CXX] vcl/source/animate/Animation.cxx
C:\lo\src\core\include\rtl/ref.hxx(129): error C2027: use of undefined type 'VirtualDevice'
C:\lo\src\core\vcl\inc\impanmvw.hxx(29): note: see declaration of 'VirtualDevice'
C:\lo\src\core\include\rtl/ref.hxx(127): note: while compiling class template member function 'rtl::Reference<reference_type>::~Reference(void)'
with
[
reference_type=VirtualDevice
]
C:\lo\src\core\include\vcl/vclptr.hxx(216): note: see reference to function template instantiation 'rtl::Reference<reference_type>::~Reference(void)' being comp
iled
with
[
reference_type=VirtualDevice
]
C:\lo\src\core\include\vcl/vclptr.hxx(64): note: see reference to class template instantiation 'rtl::Reference<reference_type>' being compiled
with
[
reference_type=VirtualDevice
]
C:\lo\src\core\include\vcl/outdev.hxx(202): note: see reference to class template instantiation 'VclPtr<VirtualDevice>' being compiled
make[1]: *** [C:/lo/src/core/solenv/gbuild/LinkTarget.mk:337: C:/lo/src/build/workdir/CxxObject/vcl/source/animate/Animation.o] Error 2
Change-Id: I78723ce7d00667595aff39bcab22169ff347098f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134036
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Map each list item to a dedicated XML element:
<loext:list-item loext:display-text="..." loext:value="...">
And do the opposite on import.
Change-Id: I59a536a8317a3bb24919107b4449f858d5f6de96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134034
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
If the lines are created with MOVETO, LINETO, LINETO...
then Line Join NONE is applied. As a result the charts are looks ugly,
with the holes inside it.
For example:
https://bugs.documentfoundation.org/attachment.cgi?id=179962
and
https://bugs.documentfoundation.org/attachment.cgi?id=179837
Additinally commit changed default line join style to miter,
as during experimenting with MS Paint and MS Word,
it appear that default Join Style is PS_JOIN_MITER and
Line Cap is Flat/Butter.
The PDF export tests has been updated, as there is less number
of PDF object after using joiners.
The size of the exported tdf145873.pptx to PDF,
was slighltly decreased from 22.8kB to 22.0KB
Change-Id: I131cc3c5e90f827d67d2360eb18167eed6315abb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133624
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
* 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>
