...to make those char class array initializations more readable. (Making the
corresponding variables constexpr is mostly done so that failures in the
provided `unencoded` arguments, like non-ASCII characters or duplicate
character typos, would lead to compile-time errors also for !HAVE_CPP_CONSTEVAL.
And assigning to a sal_Bool std::array needs another hack to avoid false
loplugin:implicitboolconversion warnings.)
Change-Id: Ieb8827f69f55f1212a9428817d5331fcb18ef1d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133058
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Having a separate sparkline context is very useful, so we can add
a custom UI when the user has the cursor over a sparkline. This
will allow a "Sparkline" tab for NotebookBar and its own deck in
Sidebar, activated only when the sparkline is present. Also the
pop-up menu can be customized specifically for the sparkline, but
this may be less useful.
For the sparkline context we need a custom shell - SparklineShell
where now all the UNO commands can be implemented (not done in
this commit).
Change-Id: Idca2ad946af3afdd1b494744b80c9c093eec602c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133022
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Move DataTableContext and DataTableModel into its own files and
add the missing "showKeys" property of the data table (dTable).
Change-Id: I44fb436000c7f00a596fc9b12489d15ea1368e68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133021
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
`Intent.ACTION_OPEN_DOCUMENT` was introduced in API level 19,
therefore `Intent.ACTION_GET_CONTENT` is supposed to be used
for older Android versions.
The previous attempt at doing so didn't work, since no
`ActivityNotFoundException` is thrown when trying
to set the action to `Intent.ACTION_OPEN_DOCUMENT` on
older Android versions.
Fix that by using a proper version check instead.
Change-Id: Ie06fa3f39e3042b4b7161a3c937bf655eb658abd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133025
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use the `ContentResolver#query` overload that is available from
Android API level 1 on, not the one that's only available from
API level 26 on [2], which would otherwise trigger an exception
if run on devices running Android version < 8.0, as seen
on an AVD with API level 21:
> E/AndroidRuntime( 2914): FATAL EXCEPTION: main
> E/AndroidRuntime( 2914): Process: org.libreoffice, PID: 2914
> E/AndroidRuntime( 2914): java.lang.NoSuchMethodError: No virtual method query(Landroid/net/Uri;[Ljava/lang/String;Landroid/os/Bundle;Landroid/os/CancellationSignal;)Landroid/database/Cursor; in class Landroid/content/ContentResolver; or its super classes (declaration of 'android.content.ContentResolver' appears in /system/framework/framework.jar)
> E/AndroidRuntime( 2914): at org.libreoffice.ui.FileUtilities.retrieveDisplayNameForDocumentUri(FileUtilities.java:137)
> E/AndroidRuntime( 2914): at org.libreoffice.ui.LibreOfficeUIActivity.createUI(LibreOfficeUIActivity.java:206)
> E/AndroidRuntime( 2914): at org.libreoffice.ui.LibreOfficeUIActivity.onCreate(LibreOfficeUIActivity.java:147)
> E/AndroidRuntime( 2914): at android.app.Activity.performCreate(Activity.java:5937)
> E/AndroidRuntime( 2914): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1105)
> E/AndroidRuntime( 2914): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2251)
> E/AndroidRuntime( 2914): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2360)
> E/AndroidRuntime( 2914): at android.app.ActivityThread.access$800(ActivityThread.java:144)
> E/AndroidRuntime( 2914): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1278)
> E/AndroidRuntime( 2914): at android.os.Handler.dispatchMessage(Handler.java:102)
> E/AndroidRuntime( 2914): at android.os.Looper.loop(Looper.java:135)
> E/AndroidRuntime( 2914): at android.app.ActivityThread.main(ActivityThread.java:5221)
> E/AndroidRuntime( 2914): at java.lang.reflect.Method.invoke(Native Method)
> E/AndroidRuntime( 2914): at java.lang.reflect.Method.invoke(Method.java:372)
> E/AndroidRuntime( 2914): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:899)
> E/AndroidRuntime( 2914): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:694)
>
[1] https://developer.android.com/reference/android/content/ContentResolver#query(android.net.Uri,%20java.lang.String[],%20java.lang.String,%20java.lang.String[],%20java.lang.String)
[2] https://developer.android.com/reference/android/content/ContentResolver#query(android.net.Uri,%20java.lang.String[],%20android.os.Bundle,%20android.os.CancellationSignal)
Change-Id: I13ecc57d3d6b25a7eb2e5ff85a3420ef8064cb20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133024
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
User input permits zero-length animations, so whenever we calculate
relative position within the animation time frame, the case
mnMinSimpleDuration == 0.0 means: we're already at the end of the
animation, i.e. set relative time to 1.0
Change-Id: I0e8c1e29f47bd9fa16f04115cf52d3a176e13fb0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133005
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
...and add tests for those additions to isBoolExpr done in
8e4d82cd11 "loplugin:implicitboolconversion: warn
about conversions to unsigned char" (and which were added to avoid false
warnings like
> testtools/source/bridgetest/bridgetest.cxx:643:21: error: implicit conversion (IntegralToBoolean) of call argument from 'unsigned char' to 'bool' [loplugin:implicitboolconversion]
> (xLBT->transportPolyBoolean(
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
and
> cui/source/options/optaboutconfig.cxx:359:62: error: implicit conversion (IntegralToBoolean) of call argument from 'unsigned char' to 'bool' [loplugin:implicitboolconversion]
> sValue.append(OUString::boolean( seq[j] ));
> ^~~~~~
)
Change-Id: I0683144e1c39d31303faf678afaafd708ef7ff79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133018
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Replace the no longer maintained Android Support Library
with the Android Jetpack libraries.
Quoting [1]:
> Version 28.0.0 is the last release of the Support Library. There will be
> no more android.support library releases. All new feature development
> will be in the androidx namespace.
Most porting was done automatically by using Android Studio's
"Refactor" -> "Migrate to AndroidX..." function.
In `android/source/res/layout/toolbar_bottom.xml` and
`android/source/res/layout/toolbar_color_picker.xml`,
the uses of
`app:layout_behavior="android.support.design.widget.BottomSheetBehavior"`
had to be replaced manually as described at [2], because
the app would crash when using the old "android.support"
values.
Also drop the Android Support Library related bits from configure.ac
In a quick test, this worked fine and no obvious
difference was visible when running this in various AVDs.
When trying to test this in an x86 AVD still using
SDK 16 (Android 4.1), which is currently specified
as Android Viewer's `minSdkVersion`, only various
unrelated issues showed up, some of which will be
handled in follow-up commits.
After the migration, many weird errors showed up in
Android Studio, which disappeared after invalidating
the caches (via "File" -> "Invalidate Caches...").
[1] https://developer.android.com/jetpack/androidx
[2] https://stackoverflow.com/questions/45100963/runtimeexception-could-not-inflate-behavior-subclass
Change-Id: I2a57f0ebd56e7ecc09b7d65aae17fd15088a633b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133002
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Using the dispatch mechanism means that this can be caught by the dispatch interceptor
which we don't want in this place.
Change-Id: Ie7e5f92e6043e2aff98d4887829a3573c12c6d08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132941
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
...which had been butchered by c7fb93764b "Cleanup
comment": e4ff847fe0 "loplugin:stringview check
for getToken and trim" had turned this into a template, but had not lifted the
other restrictions. But while at it, also adapt the mention of "OString" and
"std::string_view" in the comment to that
e4ff847fe0 change.
Change-Id: I3c27efe145c4bea6c4b16f81da671bf22160545c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133000
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
There can be no author related to total editing time,
and SAVEDATE is the modified date, so this was all
completely bogus code.
No unit tests hit SAVEDATE on a make check assert.
This all came from very early 2000 code,
at which point DI_CHANGE only handled AUTHOR,
so likely things were very confused back then,
and when SAVEDATE was connected with DI_CHANGE in 2003,
they failed to remove it from DI_EDIT.
Change-Id: Ib9108a59128d5c7fa11d350c58005a925678cb4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132665
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Gtk-CRITICAL **: 09:05:11.124: gtk_tree_row_reference_new_proxy: assertion 'path->depth > 0' failed
from TreeView::set_cursor(-1)
gtk_tree_view_set_cursor is ok (and documented as such) with an
"invalid" path to unset the cursor, but there isn't the same for
gtk_tree_view_scroll_to_cell, though there null is docs as acceptable.
Change-Id: I11b94ba997fbbd2f31031d9e73765ea1882ad9ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132996
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
In some rare cases (CppunitTest_writerperfect_writer can trigger them
on Win/Mac) the fonts used for fallback change and it's not included
in the cache key.
Change-Id: I9611d500405d0dae7f95fa4469ccfaa39de672c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132995
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Additionally to the Text/Attributes already saved/secured after
Diagram import, secure more data that is part of the Diagram
ModelData. This is about attributes (e.g. FillStyle/LineStyle,
TextAttributes, ...) in UNO API formt that will be secured/
attached to the Diagram ModelData in it's
svx::diagram::Point structure.
This is done for all those entries for which a XShape will/
would be incarnated, thus associated to entries that will
get a visualization, including the BackgroundObject.
From that data, at re-creation time, the attributes can be
re-applied to the re-created XShape(s), also after changes
to the Diagram Model Data (e.g. Add/Remove).
This is - besides the already added securing of the Style/
Theme - a 2nd method for lossless re-creation. For the
BackgroundObject - if it has FillStyles - it is even the
only method to secure that data and thus necessary for that
case. The selection of atributes that gets secured is minimal
for now and may/need to be extended for existing cases
accordingly.
Change-Id: Ie9b72b9b9135113cf858d57fe6cd8622d736c4a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132976
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
...tweaking the code slightly to guarantee that j will always be non-negative
Change-Id: Ie8ba450884cc8b12e0caa79b4d75f95dd96cc120
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132993
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
