Previously, when setting HELP_DEBUG=1, the tooltips lacked the label
(description) for the commands in extended tip mode.
The problem was that, if the extended help content was empty, then the
ToolBox::RequestHelp() function added appropriate description. But, with
the help debug mode on, the tooltip was no longer empty. It containted
seperator "-------------" and the UNO command.
This patch adds the description when the extra help content is empty and
solves the issue. The result contains mnemonic characters like ~ which
can be suitable for debugging. These characters are removed with the
call to MnemonicGenerator::EraseAllMnemonicChars in ToolBox::RequestHelp
in a normal LibreOffice session without setting HELP_DEBUG.
Keyboard shortcuts are displayed in normal mode, but not in the extended
tips mode. This issue can be later fixed by adding the keyboard shortcut
to the tooltips when HELP_DEBUG=1 is set.
Change-Id: Iead828ece855fa3e712919ef62353dbca9db1d52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211577
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
This reverts commit 05ba63c6fc.
Reason for revert: The goal is to re-introduce the example with
AWT/Swing instead of applet in a subsequent patch, while preserving git
history.
Change-Id: I1210eea93149aefb5ad0f57216b2fbdaad9c224f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199755
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Previously, multiple labels were defined for restartdialog.ui, one for
each reason! This patch modifies the ui file, leaves only one label and
sets its text for each reason of restart.
The patch is written in a way to make the changes minimal and keep the
behavior unchanged, and also keep the strings translateable with the
context preserved.
Change-Id: I3168beed6170e3bf8d3f24aa111de07177991bfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209010
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
As described in the dev mailing list, LibreOffice build fails at the
configuration stage, starting from VS 2026 version 18.7.0.
LibreOffice build errors with Visual Studio 2026 version 18.7.0
https://lists.freedesktop.org/archives/libreoffice/2026-June/094681.html
The root cause of the issue is that clang-cl.exe is re-located in that
version and configure.ac searches in the old places, and does not find
it. The new patch contains an extra 'x64', or the architecture.
Here, $WIN_BUILD_ARCH is used as the architecture.
Change-Id: Ib3e3f518735df5045241f52a2ce86184e47fc87b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208447
Reviewed-by: Hossein <hossein@libreoffice.org>
Tested-by: Jenkins
In the past, LibreOffice cross platform .NET support could correctly
build binding files, but these files were not shipped. This patch fixes
the issue, and ships these files, as described below:
$ ls instdir/sdk/dotnet/
LibreOffice.Bindings.0.1.0.nupkg
nuget.config
$ ls instdir/program/dotnet
net_basetypes.dll
net_bridge.runtimeconfig.json
net_uretypes.dll
net_bridge.dll
net_oootypes.dll
Change-Id: I947aafbf45436855dfdb7ab5f3268f42b8a66511
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208294
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
As now headless mode is possible on macOS, let's enable it in the distro
configs, so that final builds make use of this option.
Change-Id: I5c46775c597bced62a84b3f018d14305f3caa634
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200535
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
With GCC 15.2, compiler produces this error message:
[LOC] top level modules: odk
odk/source/unoapploader/unx/unoapploader.c: In function ‘createCommandName’:
odk/source/unoapploader/unx/unoapploader.c:285:13: error: assignment discards
‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
285 | sep = strrchr( prgname, SEPARATOR );
| ^
cc1: all warnings being treated as errors
By defining sep as "const char*" instead of "char*", the problem goes away.
Change-Id: If1d628dba8bb4ec657b916fa61927b250d3039c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202942
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
This patch makes it possible to build LibreOffice with Qt6 VCL plugin on
Windows.
In the configuration stage, it is required to add --enable-qt6 to the
configuration options, and also set the QT6DIR to the place where Qt6 is
installed:
export QT6DIR=/cygdrive/c/qt/6.10.2/msvc2022_64
When building with --enable-headless in addition, Cairo
based rendering is used by default, but the QFont based rendering
can explicitly be enabled by setting environment variable
SAL_VCL_QT_USE_QFONT=1 when starting LibreOffice, as is the case on
Linux.
When using the QFont based rendering, two asserts related
to logic related to alpha/transparency support not fully being implemented
for that rendering path yet are triggered (in QtVirtualDevice::SetSize
and QtGraphicsBackend::getBitmap). They can be commented for
further experiments. That also matches the behavior seens on
Linux.
For a debug build of Qt, the file names of the libraries include
an additional "d" in fron of the ".lib" file extension, e.g. a file
name of "Qt6Widgetsd.lib" instead of just "Qt6Widgets.lib",
so support both variants in configure.
This is partially based on a previous commits from jmux for Qt5 in 2018.
One may see the old patches using:
$ git checkout remotes/origin/feature/qt5-win+mac
A subsequent patch is planned to add Qt6 support for macOS.
Co-authored-by: Jan-Marek Glogowski <glogow@fbihome.de>
Co-authored-by: Michael Weghorn <m.weghorn@posteo.de>
Change-Id: I42a3059c738fa95464fa49ae4aab1c9f686fee46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199615
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Hossein <hossein@libreoffice.org>
This reverts commit 20ee295dd11fcad8ba72439e6ad28f61ed740958, such that
LibreOfficeKit headers and examples are usable on macOS again.
After 5d4a689293 and
857a760f31 among other related patches,
LibreOfficeKit became usable on macOS. The build issues are fixed in
d6773eccb3.
Change-Id: Ifaac9c3652bf4b4f53b41997015f00b9083628a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199965
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Used C++20 std::ranges::all_of() instead of a loop to simplify the code.
Also, it seemed that sort() was not necesary, so I removed that.
Change-Id: I244c862252881683d50cfe9bc140b7b6b5dfa82f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196851
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Due to the issues discussed in below change, deep links are currently
blocked on git.libreoffice.org:
https://gerrit.libreoffice.org/c/core/+/188429
Therefore, it is not possible to use the link provided in "Help >
About", as it leads to error "Secure Connection Failed". This patch uses
/commit instead of /history to show a single commit instead of complete
history.
Change-Id: Ie52e7e6a52fda3578ab955dcbf8d569a22c0009d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196087
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
The library .dylib file path was not found when building cairo for
macOS. Now it is possible to build cairo for macOS.
Built library files for cario and pixman are adjusted using the tool
install_name_tool, and also solenv/bin/macosx-change-install-names.pl
perl script which also uses install_name_tool indirectly.
From now on, macOS no longer uses the name 'libcairo' for built library
file, and it will use 'libcairo-lo' like the other platforms. This removes
the need for handling macOS differently from the other platforms.
To use headless mode, these options should be added to autogen.input:
--enable-headless
--without-system-fontconfig
--without-system-freetype
Change-Id: I1895ba651a07b1dbd8488fa973ec1d90c24de63b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194931
Tested-by: Jenkins
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
This patch modifies configure.ac in a way that LibreOffice compiles
with Visual Studio 2026.
The option --with-visual-studio=2026 should be used in the configuration
file autogen.input in order to use VS 2026.
Change-Id: I5bd0b5629264c0cb6ec3846954eded2505f06a4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193934
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
rBHelper was a local variable with the same name of a member variable of
the class ODatabaseMetaDataResultSet. With this patch, we avoid this
name duplication.
The above duplication was causing build problem with the latest VS 2026
compiler:
error C2220: the following warning is treated as an error
warning C4458: declaration of 'rBHelper' hides class member
Change-Id: Id70c690c3b09611aefab720aef1f8c8c1dd46829
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193965
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Invoking runGraphicsRenderTest() at first startup, after splash screen
progress bar reaches 100% causes significant hiccup in the application
startup. The user may think the application hanged, and that causes bad
first impression.
This patch limits this startup test to DBG_UTIL builds only.
Change-Id: I2b7ad6f229a1bf6288ba370f5f65591bd47f156a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193847
Reviewed-by: Hossein <hossein@libreoffice.org>
Tested-by: Jenkins
With JDK 25, I get 10 errors like this:
[javac] workdir/UnpackedTarball/hsqldb/src/org/hsqldb/jdbc/jdbcParameterMetaData.java:54: error: jdbcParameterMetaData is not abstract and does not override abstract method isWrapperFor(Class<?>) in Wrapper
[javac] public class jdbcParameterMetaData implements ParameterMetaData {
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 10 errors
[javac] 13 warnings
BUILD FAILED
workdir/UnpackedTarball/hsqldb/build/build.xml:353: Compile failed; see the compiler error output for details.
With this patch, code inside //#ifdef JAVA6 /* ... */ //#endif JAVA6
is re-enabled which resolves the build issue.
The issue was happening before with JDK 21. But, at that time patch
541eacf801 was enough to make the build
pass.
Change-Id: I73a8054d4382b8337fadafe579ca8cd24d644c89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182472
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
On some Linux distros, this command outputs multiple directories:
$($LLVM_CONFIG --version|awk -F. {'print $1'})
Therfore, in this patch, we extract major version first.
Change-Id: I0ed8249880c6d6057c4ada6cd9887d49c690f39a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193447
Reviewed-by: Hossein <hossein@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Previously, .NET test was bound to specific .NET version, net8.0. Now,
it is extracted from 'dotnet --version' command.
The test can be run with:
$ make DotnetTest
Change-Id: I764ff2ebe487c95049e6acdc15738bcb6434e8eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190782
Reviewed-by: Hossein <hossein@libreoffice.org>
Tested-by: Jenkins
Previously, .NET SDK examples were bound specifically to .NET 8 target
version, or "net8.0". Now, the major/minor version of .NET SDK is
extracted from the output of invoking 'dotnet --version' command to
create the project file for .NET SDK examples.
For example:
$ dotnet --version
9.0.123
Then, the target will be 'net9.0', as is expected:
$ echo net$(dotnet --version | cut -d. -f1-2)
net9.0
Change-Id: Ibea3cfa0b9b68394dab6efdf4b5c0c34f7b4e882
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190774
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Using X11 backend (gen), LibreOffice produces assertion failure on a
debug build when running with Skia/Vulkan. That is because of missing
implementation for handling transparency on that platform.
I turned the assert/TODO into a warning to avoid assertion failure.
This is supposed to be only for X11, and is tested on Linux.
Change-Id: Iea7ac732123446843aaa71748c10bc17e305fc8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190291
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
The new code uses the o3tl::convert to do the conversion, as it provides
a mechanism to do the conversion among different units in LibreOffice.
The old code used 35.27777778 as the conversion factor to convert points
to 10 microns.
1 point = 1/72 inch
1 inch = 25.4 mm = 25400 microns
factor = 25400/(72*10) ≈ 35.27777778
Please note that for values bigger than or equal 24999964, the result
can have small difference compared to the old result. For this value,
the new conversion gives 881943174, but the old formula gives 881943175
which is slightly inaccurate, off by 1. In this case, the new conversion
using o3tl::convert() is more accurate.
Change-Id: Ifcda6f9ad2f3f4d0f623ca157edbd0b4f44041fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189970
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Hossein <hossein@libreoffice.org>
Previously, JDK version number and path were displayed as RTL in right
to left mode of LibreOffice, in "Tools > Options > Advanced". The RTL UI
can be activated by setting:
SAL_RTL_ENABLED=1
The fix uses an LRM and PDF Unicode characters around the text:
https://en.wikipedia.org/wiki/Bidirectional_text
This patch also fixes the display of JDK path, which had the same issue
that was visible in the bug doc.
Change-Id: I80b25821defd43355e5b271d0348dd70ef520440
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187813
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
As code completion is always available in Tools > Options, and it is
there for a long time, it is no longer relevant to make it visible only
when experimental features are enabled.
Change-Id: I4e80daa92b07745c1bca065c8239df283c69b883
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183171
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Jenkins
There was some SID collisions in the below file which should have been
avoided:
* include/svx/svxids.hrc
The collision occured over the offset of 450:
$ git grep -n "SID_SVX_START + 450"
svxids.hrc:385:#define SID_EDIT_DIAGRAM ( SID_SVX_START + 450 )
svxids.hrc:542:#define SID_SB_STARBASEOPTIONS ( SID_SVX_START + 450 )
$ git blame -L 542,542 include/svx/svxids.hrc
cb05db521e (Vladimir Glazounov 2007-04-11 15:30:44 +0000 542)
$ git blame -L 385,385 include/svx/svxids.hrc
cfb68712a4 (Armin Le Grand (Allotropia) 2022-03-02 11:52:14 +0100 385)
As described in 1b4997d7a84d1, it is possible to use grep to make sure
no collision is remaining:
$ git grep -h "SID_SVX_START[ ]*+" *.hrc | grep -Ev '^\s*\/\/' \
|awk -F\( {'print $2'} | awk -F\) {'print $1'} \
|awk '{gsub(/^ +| +$/,"")}1'|sort|uniq -c|grep -v " 1"
If there are any results, it means occurrence of some collision.
Change-Id: I252c582bac7d92e98e56c2834715e1766244aa52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183446
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
With Unicode literals, the code is now much simpler. This patch also
corrects the text, which means 1 2 3 in Arabic.
Change-Id: I59a6a3afcddde416f73e74287319750cf4111048
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182826
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Previously, vcl app with gen UI backend was always crashing when no
translation files where available. This patch fixes that for gen UI
backend.
This crash happens in minvcl example, when changing one of the LibreOffice
ui files to a minimal Glade .ui file that contains the used UI elements.
One can run the minweld example with gen ui backend with:
$ export SAL_USE_VCLPLUGIN=gen
$ ./bin/run minweld
Change-Id: Ia3bf7671577b6b8013cae9b54a5469213bf65601
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178750
Reviewed-by: David Gilbert <freedesktop@treblig.org>
Tested-by: Jenkins
The previous command was not working, because of the lack of absolute
path and also the wrong path to the test document. This should be fixed
now.
Change-Id: I2230041e17e4b6b33cfd44e5f15a5fce086a5f1c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176764
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
While trying to load notebookbar.ui for sc I found that there are issues
with the .ui file itself:
* Duplicate IDs, created in 608e1452c5
* Typo in the attribute names, created with the manual edits in
04ed7cbe53
This patch fixes above problems.
Now, one can preview the notebookbar.ui for sc with:
$ export GLADE_CATALOG_SEARCH_PATH=$PWD/instdir/share/glade
$ glade-previewer -f sc/uiconfig/scalc/ui/notebookbar.ui
Change-Id: I83be23f4a2a24a04f4fa8b627c138bc42bdf6916
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176619
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
The "minweld" is a minimal standalone vcl application that uses the
LibreOffice vcl weld framework to display the "tip of the day" dialog on
the screen. Upon clicking on the "Next Tip", a counter is incremented
and the text label containing its value is displayed/updated in the
center of the dialog box.
One can run the application by invoking:
./bin/run minweld
This example uses cui/ui/tipofthedaydialog.ui for the UI, but only uses
a few elements of it.
Change-Id: If304c60ddb262182cf23438ed1f83dba85e66391
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176610
Reviewed-by: Hossein <hossein@libreoffice.org>
Tested-by: Jenkins
Previously, AdditionsDialog was not working while in start center. Also,
there were a lot of code duplicates. This patch fixes these issues.
The UNO command .uno:AdditionsDialog was incorrectly implemented as
application specific. There were multiple duplicate conditions for
checking SID_ADDITIONS_DIALOG in each and every application. Now, this
is only done in sfx2/source/appl/appserv.cxx in a single point.
The AdditionsDialog can now be opened while in start center in different
places of "Tools > Options" for icons, dictionaries, etc. Also, this
LibreOffice BASIC code snippet opens it:
Sub Main()
oDispatch = CreateUnoService("com.sun.star.frame.DispatchHelper")
Dim args(0) As New com.sun.star.beans.PropertyValue
oDispatch.executeDispatch(StarDesktop.ActiveFrame,
".uno:AdditionsDialog", "", 0, args)
End Sub
Change-Id: Ifb7e466449008b9bb6e5b678da2e54f58bc101e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174469
Reviewed-by: Hossein <hossein@libreoffice.org>
Tested-by: Jenkins
In wsl, Windows path is also added to the WSL shell path. Therefore,
dotnet.exe from Windows is also found, if it is searched for, causing
build issues.
To avoid the build problem, and in general, to avoid using Windows
builds from outside the WSL container, search for dotnet.exe is only
done on Windows builds.
Change-Id: I2c8c412f08008b24faf50d00dc166ad7a3c09b23
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172175
Tested-by: Hossein <hossein@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
While changing the code to use std::optional instead of bool, some
unwanted code behavior changes were introduced in this commit:
commit fbe8071e4f
Date: Sat Oct 15 14:20:31 2022 +0200
refactor functions: return optional instead of bool
Part of those unwanted changes are fixed in this commit:
commit 243e811abc
Date: Wed Jun 5 10:14:49 2024 +0100
cid#1603200 Uninitialized scalar variable
cid#1603199 Uninitialized scalar variable
This commit undoes changes in the above (second) commit, and tries to fix
the problems by making the code look closer to what it was before the
first commit.
Change-Id: I47d692a5cf46abad582d7f162e2180e6c26b7e5d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169037
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
With LibreOfficeKit (LOK) headers in place, it would be possible to
create C++ applications that can access LibreOffice functionality
without building LibreOffice, only by installing SDK and build tools.
Change-Id: I8efc8ac1cec7b3b89e4d7eb2c8d15afeb595672c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134863
Tested-by: Hossein <hossein@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
These settings are available to set the brand when building LibreOffice:
1) Community flavor: yes / no
This is set via --disable-community-flavor, that defines
HAVE_FEATURE_COMMUNITY_FLAVOR, which is used in cui/source/dialogs/about.cxx.
2) Product name: A string (set via --with-product-name='name')
This defines PRODUCTNAME, which is used in many places in the code.
Not every LibreOffice build is a "LibreOffice Community" flavor. This
patch fixes this issue by using community brand only when variable
HAVE_FEATURE_COMMUNITY_FLAVOR is set.
Change-Id: Ib74450f380fed7c24222f88e389ddb5363bda3c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168676
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Jenkins
Previously, in SDK examples, de-referencing was done unconditionally
after obtaining a reference using UNO_QUERY. Now, we use UNO_QUERY_THROW
instead, to make sure cases where exceptions may occure can be handled
correctly.
Change-Id: Ic73ba3cfcad914dabb7ae3736ad1ae2bd6cc15bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164682
Tested-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
Changing the links to keep them up-to-date was previously done only when
the name "Slide" was used for the pages, just like Impress, as Draw and
Impress share code. Now, the term "Page" is used instead of "Slide"
since 942d1d2ea5 in Draw. This change,
fixes the above issue by also using the correct string consntant.
The patch is tested for Draw and Impress to make sure both are working
correctly now.
Change-Id: I55b4f56bd499d05f87f475d4c6cb3423247bf8d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164716
Tested-by: Jenkins
Reviewed-by: Stéphane Guillou <stephane.guillou@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
Port DevelopersGuide/FirstSteps/HelloTextTableShape Java SDK example to
C++ and add a GNU Makefile for the build.
Change-Id: I8798406c24ec6c566fb6494f7202f6a2a984a25c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164635
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Commented code in the HelloTextTableShape.java example demonstrates the
use of bookmarks. This part is now enabled.
Change-Id: Iace525be0d53b01bed8b5a6a123384a678d1d761
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164636
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Previously, maximum number of field columns for data form was 256, which
was too much. But, even with that value, nothing was happening when
exceeding that threshold. With this patch, the limit is decreased to 32,
and if the user goes beyond this limit by selecting more columns, an
error message is displayed. This change is done to prevent LibreOffice
hang when excessive number of filed columns are selected and using data
form is requested.
Change-Id: Ib6189b5b3beffb26a3fd8ba8cd06e4ae213f77da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162488
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Call to gb_JunitTest_add_classes was missing in the gbuild makefile
sw/JunitTest_sw_complex.mk, and now it sholud be fixed. Before that
the sw/qa/complex/indeterminateState/CheckIndeterminateState.java was
compiled, but it was not run due to the missing class name
(complex.indeterminateState.CheckIndeterminateState) from the java
command which was used to invoke the test.
The test can be run with:
$ make JunitTest_sw_complex
Change-Id: I85823336d7f3ad2fde47442b5d1c5d2f3003299b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162263
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
This is a minimal Python extension. It is possible to run main.py from:
1. Inside a LibreOffice extension
2. Inside LibreOffice, and also via APSO
3. Outside LibreOffice, as an external process, and also in a Python IDE
The provided Python script is very useful for debugging extensions as an
example. That is because it is possible to debug it in an IDE before
packaging it as a LibreOffice extension.
Python file is checked with:
$ flake8 --ignore E501 main.py
Change-Id: I24d9aefdfda29264bf6b5f9403a40fae35e610f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159938
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
One parameter of SfxStyleSheetBasePool::Make function was changed in
0035573ee7, but that change was not
reflected in the comment. It is now updated.
Change-Id: I89f7c1a6e0424d11acddf1f94d3af370af691b36
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161611
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
This fixes some minor issues with the make files for Java/C++ SDK
examples in DevelopersGuide/FirstSteps.
For Java examples, an exatra "-f Example_Java.mk" was a leftover from a
previous change.
For C++ examples, 'make clean' was not working correctly, because of a
leftover from a previous change.
Both should be fixed now.
Change-Id: Id936824675a9bfd43674ca526bc97a998ed9daf8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159777
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Port DevelopersGuide/FirstSteps/FirstLoadComponent Java SDK example to
C++ and add a GNU Makefile for the build.
Change-Id: I24da0422014e42f844cae21863d54301dd902f0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159740
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
This patch creates separate folders for 3 different SDK examples in
DevelopersGuide/FirstSteps:
1. FirstUnoContact
2. FirstLoadComponent
3. HelloTextTableShape
Each one of these are ported to 4 languages: Java, C++, BASIC, Python.
The Java Makefile in the top folder is now separated into 3 different
Makefiles for Java programs.
Change-Id: Ifb2003be2aafb4caec4810eb21fbb4708b9a0628
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159591
Tested-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
First comment was last updated with USHORT -> sal_uInt16 in
a2242be9c3 but with the newer commit
68ec95b3f8 there is no remaining sal_uInt16
left, and thus the comment is no longer relevant.
Second comment was added in 1fac87f847,
but with changes in 444c242c51 it is no
longer relevant.
Third comment was also last updated with USHORT -> sal_uInt16 in
a2242be9c3 but with the newer commit
444c242c51 it is no longer relevant.
Change-Id: I9ed383f15a5b403740c0b8bcdd153d04bb1a2b0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158111
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Previously, svptest VCL example was not built on all paltforms. Now,
svptest is built on Windows and elsewhere. To run, one can invoke:
./bin/run svptest
Change-Id: I915a4ef9748e2248d2d209969d1fef079ee06cff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156972
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
On Windows/Cygwin, if you put "C:\Program Files\LibreOffice\program"
in PATH, bin/run will have trouble finding correct vcllo.dll and other
LibreOffice .dll files inside instdir/program. Because the script uses
the absolute path of the executable, it is enough to use instdir/program
as the current working directory.
The symptom was that in the above case it was not possible to run the
workbenches like vcldemo, minvcl, etc. The error was:
$ ./bin/run minvcl
minvcl.exe - Entry Point Not Found | The procedure entry point
?RasterFromBitmap@SKImages@@... could not be located in the dynamic
link library vcllo.dll
$ ldd ./lode/dev/core/workdir/LinkTarget/Executable/minvcl.exe
...
comphelper.dll => not found
fwklo.dll => not found
i18nlangtag.dll => /cygdrive/c/Program Files/LibreOffice/program/i18nlangtag.dll (?)
sal3.dll => /cygdrive/c/Program Files/LibreOffice/program/sal3.dll (?)
vcllo.dll => not found
MSVCP140D.dll => /cygdrive/c/WINDOWS/SYSTEM32/MSVCP140D.dll (?)
VCRUNTIME140D.dll => /cygdrive/c/WINDOWS/SYSTEM32/VCRUNTIME140D.dll (?)
VCRUNTIME140_1D.dll => /cygdrive/c/WINDOWS/SYSTEM32/VCRUNTIME140_1D.dll (?)
ucrtbased.dll => /cygdrive/c/WINDOWS/SYSTEM32/ucrtbased.dll (?)
Change-Id: I02b6d9aca1062b22a91d5a1f9bce0cf7238a896a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156902
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
The loop was over an array which has only one element, so the
condition should also work directly with its only element.
Change-Id: I5b87cf03d90e9da67ac3ff72b593be0ff5fa322c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129677
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Previously, when using ctrl+end, the screen/cursor jump was done to the
middle of the screen. In this way, the available space of the screen was
not optimally used.
In this patch, the jump is adjusted to move the cursor to the end of the
screen, and the visible/usable space will be all of the screen.
In this patch, previous behavior for showing the search results and
other purposes other than pressing ctrl+end to jump to the last cell are
preserved, and in those cases, the selected cell will be in the middle
of the screen, as before.
Also, in the situations that the jump is done from a cell lower or right
of the last cell (in other words, further than the last cell), the
behavior is preserved.
Change-Id: I25f308f84f096ec271c23df75998ddeea32119ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156266
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
This reverts commit 97b61ea329. It checked
that the NativeLibraryLoader is an instance of the class
com.sun.star.lib.unoloader.UnoClassLoader. If this is not the case, a
warning was displayed. This was for java_uno bridge to work.
On the other hand, as the comment in the code implies, "not a problem
if this is using Java remote bridge or (in a) unit test". But, in the
code there was no check for that. As a result, this warning is displayed
in many places like the simple examples that want to connect to the
LibreOffice process via Java API.
Change-Id: I056ed372ad071573051024a63e51afd6b4425ce5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156302
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
When using numerals in "context" mode in "Tools > Options", in
"Language Settings > Complext Text Layout > General Options > Numerals",
the actual display of the numbers is dependant on the direction and
the language of those numbers.
Previously, when exporting the DOCX in LO the RTL direction was lost,
and because of that, the numerals were shown incorrectly after saving
in LibreOffice, and loading again.
This patch adds <w:rtl/> where <w:lang> contains an RTL language.
For example, before <w:lang w:bidi="fa-IR"/> inside <w:rPr>, it always
adds <w:rtl/>.
It is worth noting that this is not always the case, as there are
situations that <w:rtl/> is not present in <w:rPr> with an RTL language
like <w:lang w:bidi="fa-IR"/> and <w:rtl/> should not be in the output.
This patch does not handle that case, because currently loading such a
text is not done correctly in LO, and the LTR numbers inside RTL
environment are shown just like RTL numbers. To fix it, first loading
and displaying of that should be fixed.
A test is added to check the export of the sample file, which can be
invoked with:
make CppunitTest_sw_ooxmlexport CPPUNIT_TEST_NAME=testTdf155470
Change-Id: I8fc54916fcd3295010c5c81ccb632bc6082ffaa2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155721
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
This patch fixes the recent problem with building LibreOffice with ccache
on Windows which was caused by the lack of double quotation mark between
ccache.exe and path to the MSVC compiler.
Change-Id: I1a714513ccb8cd674895d0c887013ea862d3b544
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152277
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Clicking on an RTL header previously lead to assertion failure, but now
it is checked if the SwFrame pointer is null. If so, an empty vector is
returned.
It should be noted that the rendering of the rtl header in the
attachment 188689 is still wrong as the text and image are misplaced.
A test is added to the patch, and can be run using:
make CppunitTest_sw_uiwriter8 CPPUNIT_TEST_NAME=testTdf156560
Change-Id: I9e8f66895b4ef9369300c9d7c03d22a2085a1d71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155159
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
UITest loads a minimal .fods example to check if Calc crashes with that.
The example file does not crash without UI, as it needs the ###
indication to be painted on the screen. Calc does not crash with the
CppUnitTest, tested using testImportCrash() to load the file in a test
added to sc/qa/unit/subsequent_filters_test4.cxx. Also, PDF export works
without problem. But, UITest leads to crash without the fix in place.
The UITest can be run using:
make UITest_calc_tests9 UITEST_TEST_NAME=tdf156268.Tdf156268.test_tdf156268
Change-Id: I9712d70f057cfc11f10fd98caadbf6e10ee67d5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154977
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
This fprintf was leftover from 1653bb9bff
which came up with attachment 94167 from tdf#75059 in terminal output
with just opening and closing in the official 7.5.1.2 binaries.
Change-Id: Ib04b5f6dd3426e97a14b3c6f38b68481f1bf85b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154518
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Previously, an old method using RasterOp::Xor rendering (see tdf#38844)
was used to draw the extra triangle left or right of the mouse pointer
in direct cursor mode. Now, instead of drawing it manually, we change
the cursor type to somewhat similar pointer type.
There is no perfect match for the previous mouse pointer shape, so now
instead of left triangle, PointerStyle::AutoScrollW is used. Also instead
of right triangle, PointerStyle::AutoScrollE is used.
Change-Id: Iadb955f9fcee0978a190e0b8920186a2579f3a4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153099
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
There were a lot of repetitions in the code of the function
SvxConnectionPage::Reset(). This patch Simplifies this function by
introducing SvxConnectionPage::lcl_SetMetricValueAndSave() to do the
repetetive instructions.
Change-Id: I337ccf2281fd8d1bd9b1948beb6d31b2306eb339
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151820
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
The last usage of boost in writerfilter was <boost/lexical_cast.hpp>.
This is now implemented using rtl::math::stringToDouble(). To avoid
behavior change in case it does not find any suitable characters to
convert, it is checked that the index of the last parsed character to
be zero, as lexical_cast throwing bad_lexical_cast exception in this
case but stringToDouble reports rtl_math_ConversionStatus_Ok.
OUString::toDouble() is not enough here, as it does not provide suitable
error handling mechanism beyond IEEE 754 special values and 0 as output.
stringToDouble() should be able to handle 16-bit char strings, as it
takes std::u16string_view type string as input, and also uses sal_Unicode
as the data type for the separators.
The boost library is no longer in use in writerfilter. But, right now it
is not possible to remove the remainings from the makefiles and includes,
because of the dependencies that still use boost.
Change-Id: Iae4b83106fcbdded71e7d9e5f70376ab408e9b5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139279
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The UITest for tdf#150457 is now ported to CppunitTest. The new test can
be run by:
make CPPUNIT_TEST_NAME=testTdf150457 -sr CppunitTest_sw_uiwriter3
Without the fix d05c176cc0 in place,
running the test leads to a segfault.
Change-Id: I1d633cadf9f5579cdf3e1e59641108eadc7b7073
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151330
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
This test checks the position of RTL/LTR elements in the exported PDF
files. Without the fix in place, the test fails because the RTL elements
will position as LTR, and the "Rect" element will be something else:
double equality assertion failed
- Expected: 303.349
- Actual : 56.699
- Delta : 1e-06
The Sample DOCX file contains both RTL and LTR content controls for testing.
One may run the test with:
make CPPUNIT_TEST_NAME=testTdf152246 -sr CppunitTest_vcl_pdfexport
For an overview on PDF fill-in forms, please refer to:
James C. King, Introduction to the Insides of PDF, pages 81-85
https://www.adobe.com/technology/pdfs/presentations/KingPDFTutorial.pdf
Change-Id: I6c15b49bffb1aef6f137f7bb518a291f4d88b888
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151228
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
With this patch, the horizonal position of the content control fields
are corrected. Previously, they were calculated just like the fields in
the LTR paragraphs. To implement this, I've used the
GetTextFrame()->SwitchLTRtoRTL method.
The remaining issue is that The exported fileds in the PDF are still LTR
themselves. For example, the combo box will still be LTR.
It should be pointed that handling vertical text is still an issue that
should be addressed later. If you rotate the paragraph with content
control field, the output does not obey, which is incorrect.
Change-Id: I927d14f9ca90434b4397dcf175dbb9531dda0c7c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150515
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
The test checks that the text shape width is smaller than the chart
wall. This test fails on HiDPI displays. For example:
--------------------
lode/dev/core/chart2/qa/extras/chart2import.cxx(2207) : error : Assertion
Test name: Chart2ImportTest::testFixedSizeBarChartVeryLongLabel
double equality assertion failed
- Expected: 4800
- Actual : 4632
- Delta : 100
Failures !!!
Run: 85 Failure total: 1 Failures: 1 Errors: 0
--------------------
Now, instead of testing the
exact value of the text shape width, I have used CPPUNIT_ASSERT_LESS()
to make sure that the above condition holds:
CPPUNIT_ASSERT_LESS(xChartWall->getSize().Width, xXAxis->getSize().Width)
This is done in two different tests:
* Chart2ImportTest::testFixedSizeBarChartVeryLongLabel()
* Chart2ImportTest::testAutomaticSizeBarChartVeryLongLabel()
Both tests are among those that can be invoked with:
cd chart2 && make CppunitTest_chart2_import
Change-Id: Ifb28fcf91da451aecdadff7a95aa810ef16fc510
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146815
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
MS telemetry inside VsDevCmd.bat causes problems for the autogen.sh
script which uses it to find the Visual Studio C/C++ standard library
via the environment variables that show the UCRT path and version.
VsDevCmd.bat is the "Developer Command Prompt for Visual Studio".
The telemtry is disabled by:
set VSCMD_SKIP_SENDTELEMETRY=1
This change resolves the problems described in tdf#153476.
Change-Id: I8b77a2ca0c3577b3ba490723ab7901f463562578
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146677
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Previously, minvcl and svdemo VCL examples were not built on Windows.
With this patch, both of the minvcl.exe and svdemo.exe are built on
Windows. To run, one can invoke:
./bin/run minvcl
and:
./bin/run svdemo
Change-Id: I43bfb314b41c662250615486a3ca783fc6d82600
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146264
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
This partially reverts 3cc818c38e. In this
patch sal_uLong was converted to better data types. In part of the patch
the order of the calls, GetVisibleSize() ~> SetLineSize ~> SetPageSize()
was changed so that the GetVisibleSize() is invoked inside the parameter
passing to SetPageSize() to avoid creating a temporary variable.
As sberg mentioned, it was needed that the call to SetLineSize() did
not have side effects that changes the result of the GetVisibleSize().
But it was hard to prove so, even if it seemed logically sound. Thus,
I am reverting the above commit partially.
In the revert, I've used tools::Long for nVisSize instead of sal_uLong.
Change-Id: Iba8d2da2675c237e9ab1c30918defce13ea71d7c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144617
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
In the regression introduced by c2c37eadf3
the bitmap image scale was calculated incorrectly. Upon resizing the
image a bit, this problem went away, and the image was shown with much
better quality compared to what it was before the above commit. It
turned out that the problem happened when the scale was less than 1, and
it was happening inside "if ( nScaleX < 1.0 || nScaleY < 1.0 ) {...}".
The part that was calculating aPosAry.mnSrcWidth and aPosAry.mnSrcHeight
was wrong, because it was setting the same height and width without
considering the fScale. The bitmap was scaled using Bitmap::Scale()
parameter which was newly multipled by fScale in the above commit. To
fix the problem, these two values are now multipled by fScale.
Change-Id: I8c77d2db3b05da54f1999d3915a70e3b7cc8106f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142754
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
This patch fixes tdf#152012 which caused an assertion failure on opening
date picker field in a DOCX file
The assertion was:
include/o3tl/span.hxx:83: constexpr o3tl::span<T>::value_type& o3tl::
span<T>::operator[](o3tl::span<T>::size_type) const [with T = const
int; o3tl::span<T>::reference = const int&; o3tl::span<T>::size_type
= long unsigned int]: Assertion `pos < size()' failed.
And the backtrace was:
1 __pthread_kill_implementation pthread_kill.c:44
2 __pthread_kill_internal pthread_kill.c:78
3 __GI___pthread_kill pthread_kill.c:89
4 __GI_raise raise.c:26
5 __GI_abort abort.c:79
6 __assert_fail_base assert.c:92
7 __GI___assert_fail assert.c:101
8 o3tl::span<int const>::operator[] span.hxx:83
9 OutputDevice::ImplLayout text.cxx:1396
10 OutputDevice::DrawTextArray text.cxx:948
11 Calendar::ImplDraw calendar.cxx:71
12 Calendar::Paint calendar.cxx:1133
The problem was caused by an out of bound access to a vector of integers
which was created for rendering calendar header consisting of the first
letters of 7 days of week, when you clicked on the down arrow on the
date field.
The function OutputDevice::DrawTextArray() takes an 'rStr' string to
draw, and 'pDXAry' array for the exact position of the the individual
characters. It also takes 'nIndex' as the first index, and 'nLen' as the
length of the array. 'nLen' has the default value of -1. In this case,
the length is calculated from the size of the string passed to the
function. This works well if the one who uses the function makes sure
that the size of the array and the length of string are equal.
Previously, for the 7 days of the week, a 7 letter string "smtwtfs"
(depending on the week start day this can be different, but length is
always 7) was sent to this method without providing the length, thus
the string length: 7 was used. In this case, positions of the letters
were calculated and used from other array named mnDayOfWeekAry[7].
mnDayOfWeekAry[k+1] was used as the position of letter k (k=0..5).
In this case, there was 7 letters for 7 days, and only 6 positions
provided by the array. This caused assertion failure in span.hxx:83
when trying to accesss mnDayOfWeekAry[7] via o3tl::span<T>::operator[].
Value of mnDayOfWeekAry[0] was used in other calculations, therefore to
fix this problem, mnDayOfWeekAry was extended from 7 to 8, and the last
position was set to the end of drawing rectangle.
The other thing that is done in this patch to avoid this problem in the
future is removing the default value from the function prototype, so
that the use should always be done by providing the length of array and
starting index. After removing these defaults, it became necessary to
provide empty arrays for 'pKashidaAry' which provides the kashida
positions, if needed.
With this fix in place, the assertion failure no longer happens.
A UI test is added to make sure the crash will not happen again. The
test can be run by invoking:
cd sw && make -srj1 UITest_writer_tests5 \
UITEST_TEST_NAME="DateFormFieldPropertiesDialog.dateFormFieldDialog.test_date_picker_drop_down" \
SAL_USE_VCLPLUGIN=gen
Change-Id: I347afb358fbc4956524f7f0a0abc3a221bf42992
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142642
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
This reverts commit 64469bb1a7.
To keep the compatibility with C++98, we need to revert the previous patch.
Quoting sberg:
"This code happens to not normally be processed (see ure/source/uretest/README)
and is meant to be compilable with the 3rd-party UNO compiler baselines (i.e.,
just C++98, which implies no range base for loops)."
Change-Id: I1355a29af24299a99a23dfcd1dd473894d7c9e0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142302
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Previously inserting charts for tables with merged cells lead to crash.
This was because a wrong assumption in unochart.cxx, specifically
SwChartDataProvider::Impl_createDataSource() that every row has the same
number of columns. Therefore the code was using the number of columns in
the first row as the number of columns for all the rows, which is wrong.
For example, inserting a chart for the second column of this table leads
to a crash:
[ ]
[ 1 ][ 2 ]
In this way, an assertion failure was created because the number of
columns where counted from the first row, which has merged cells, and
therefore fewer number of columns compared to the last column of the
selected part.
To solve tdf#149718, now we use the maximum number of columns calculated
across all the rows. In this way, the remainder of the function does not
need a fix, although a cleanup for the whole function can be interesting
and help avoid using tiny extra memory space.
A UITest is provided to avoid this bug in the future. To run the test:
cd sw && make -srj1 UITest_sw_chart \
UITEST_TEST_NAME="tdf149718.tdf149718.test_chart_from_table_with_merged_cells" \
SAL_USE_VCLPLUGIN=gen
Change-Id: I3c1000d7f177417e98d3a8ceae7886824c1053a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140092
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
With the patches 3901e02..62ff105 from Khaled, many problems with the
justified Arabic/Persian text which were related to Kashida are fixed.
Here, we add a test for tdf#139627 which converts the example file to
the PDF format, then checks the width and the position of the characters
in the output to make sure:
* The characters are present in the PDF file in the correct order
* The characters are joined together
* The diacritic mark is positioned correctly
* The overlapping of the tatweel character is not more than 10% of the
first character
Sample odt file uses "Noto Arabic Sans" font, which is available via
LibreOffice on all platforms.
One may run the test with:
make CPPUNIT_TEST_NAME=testTdf139627 -sr CppunitTest_vcl_pdfexport
Change-Id: I7a826a1b43ee842978decb0cf9a5e2a3b7219982
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138328
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
The regression was caused by 402f36efb215338ad545caa65d39fb8a39685ea1.
Before that, 0aa0fda640 changed the cursor
jumping behavior to fix tdf#81226. The goal was to make LibreOffice
behave as described in the description of the issue:
"When your cursor is on the last line but not at the end of it, simply
press the down arrow to go at the end of the file (end of that line)."
The same behavior was achieved for pressing down on the last line.
The above patches allowed removing the footnotes and their numbers
(except the first number) while the reference were still present. Then,
on hovering a removed footnote reference, a crash was happening. It
should be noted that even with this patch, removing the first reference
number was not possible.
This fix limits this behavior to anywhere other than inside a footnote.
In this way, it prevents crashing.
With this fix, the behavior of the cursor goes back to what it was
before 0aa0fda640. The user will not be
able to select all the footnotes at once. Also, removing footnote number
will not be possible.
It is worth noting that not being able to select all the footnotes at
once prevents the user from changing the characteristics of the
footnotes all at the same time. Also, not being able to remove the
footnote numbers, prevents the user from having footnotes with custom
numbers written manually. Both of these actions are possible in MS Word.
The other difference is that by going up, one can go out of the footnote
section in MS Word, but this is not the case for LibreOffice.
A UI test is added to make sure the crash will not happen again. The
test can be run by:
cd sw && make -srj1 UITest_writer_tests2 \
UITEST_TEST_NAME="deleteFootnotes.tdf150457.test_delete_footnotes" \
SAL_USE_VCLPLUGIN=gen
Change-Id: I1ce7d2189355f6763b6f31219e00516ff7a8164e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138562
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
The previous output contained extra file names other than executables,
but now we limit the output to *.bat and *.exe files.
Change-Id: Ie785d1e4388780b290f6580d02af635279080412
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138556
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
On Windows, the script did not run correctly because of the "return"s.
Here, we use "exit" instead.
Also, there were many files with the same name but with different
extensions in the output. Now, we only print out the names using grep,
awk and sort utilities.
In addition, a description for bin/run is added to bin/README.md
Change-Id: Ifb106c89199ebc5a9debf6caef80bd1edf143b20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138514
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
bin/run script is described as:
"simple wrapper script to run non-installed executables from workdir".
When the bin/run script was used without parameters, it was generating
error as it could not run the folder workdir/LinkTarget/Executable.
Now, we print usage instructions in this case, or when help is
requested with -h, -help or --help.
Also, now user can get the list of executables with -l, -list or --list.
In normal execution, the script's name is also printed. For example:
$ ./bin/run minvcl
Setting env variables and running workdir/LinkTarget/Executable/minvcl
...
Change-Id: I5c62c300d5247f55d1d1cfd095cecffc979d494b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137626
Tested-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
Using "Tools > Protect Spreadsheet Structure...", it is possible to
protect the structure of a spreadsheet document. Without this patch in
place, the [+] (add new sheet) button is clickable but it does not work.
This is confusing for the user, so it was decided that the button should
be disabled when the structure is protected.
This patch disables the [+] button just after the structure is protected
using the above toggle menu option. The menu option becomes checked, and
the [+] button gets disabled immediately. After choosing the same toggle
menu option again, the check mark goes away, and the [+] button becomes
enabled immediately.
In this patch, GetDocument().IsDocEditable() is used to check if the
document structure is protected. The argument for this choice is that
the same function is used when renaming a sheet with
ScDocFunc::RenameTable().
Change-Id: If812d94841d3efd98d7ef898cc1f4b2f1387130b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137365
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
As discussed in the ESC, although LibreOffice can be built with the
Java Development Kit (JDK) version 9, the JDK 9 is no longer
supported by the JVM vendors including Oracle, Red Hat and others.
Thus, it is asserted here that JDK 11 or later should be used to build
LibreOffice.
For further information on the supported versions of JDK, and its
lifcycle, see these articles:
Oracle Java SE Support Roadmap (Updated March 22, 2022)
https://www.oracle.com/java/technologies/java-se-support-roadmap.html
OpenJDK Life Cycle and Support Policy (Updated November 22 2021)
https://access.redhat.com/articles/1299013
It should be noted that JDK 8 is still supported, but it is not usable
for building LibreOffice.
It is also documented that without Java one may lose many features that
are described in the TDF wiki article Development/Java:
https://wiki.documentfoundation.org/Development/Java
Change-Id: Id001c341a221b0fe5c07c7129956a824261d32c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135557
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Add Makefile for the DevelopersGuide/FirstUnoContact C++ SDK example.
The example now can be built using the same process for other C++
exmaples.
The DevelopersGuide examples will be categorized into several
directories, according to the language:
basic cxx java python
This requires that all examples ported to each of these languages.
Change-Id: I95c5c324fef66664836b5e07bf34c98117e6b478
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134596
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Hossein
