The Yocto-based GNOME 3.20 SDK used to build the LO Flatpak has a broken
xml2-config. I cannot understand why the previous workaround worked fine with
raptor2-2.0.9 in LO 5.2 and fails with raptor2-2.0.15 since LO 5.3, but this
updated workaround keeps raptor's configure happy.
Change-Id: Ibfb2cb8a718f744e1bb4045082520fb186d6062b
...after 1461ebbbb5d47d90e31f0945a4878a68fbee5213 "expand out
::sax::Converter::convertNumber to OUString::number"
Change-Id: I62b9cbb83b1d4be2b2e97d3c938eb7a8ee46bc85
after commit dce867e8c4863c969eea3515a988630b74708a43
"loplugin:stringconstant handle calls to constructors with one arg"
Change-Id: Ib572d904a95aa96aab3c799f9b7cfb505fcee5e6
which results in much simpler code overall, there is no need to go via
an OUStringBuffer all the time
Change-Id: I69eba92c93f471fa9a45f97c29c56dcf3cd1ebf8
Reviewed-on: https://gerrit.libreoffice.org/33773
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
the path in gbuildparse changed, so this patch re-adapt this
2 IDE integration
Change-Id: I5f7a679b8b12eac6f44030a33713ff19327b9d1a
Reviewed-on: https://gerrit.libreoffice.org/33815
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
The test case itself is derived from tdf#43831.
Change-Id: Ifd847e84b84b02c1eb74572303af729c30c4f380
Reviewed-on: https://gerrit.libreoffice.org/33818
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
Tested-by: Kohei Yoshida <libreoffice@kohei.us>
This simplifies its usage a bit.
Change-Id: Idd5b24897f65c7cf8b7ff88806dd058c35c95ffe
Reviewed-on: https://gerrit.libreoffice.org/33817
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
to the place where we actually parse the filtering rules for advanced
filter queries.
Change-Id: I87650227e15fa54303efd720530d31ecf9827226
Reviewed-on: https://gerrit.libreoffice.org/33816
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
Previously, the fieldmarks couldn't be removed with backspace or
deletee when cursor was right/left to them.
After commits f72b866c9cf4f07fce6744fbf482c4c6488106e2 and
c34fc4520dfee4ca068f249ee0756dacaa7a60cf, deletion worked wrong
(it didn't delete the mark from mark manager; in case of text
field, it removed one field's boundary).
Now single backspace/delete properly removes the whole fieldmark,
replacing it with its contents if applicable.
Change-Id: Id26e6e4e40e274d9fd6f0224f3e2b4fe33c369b7
Reviewed-on: https://gerrit.libreoffice.org/33812
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
In a build with -fsanitize=address, this fails with:
Change-Id: If8581363a395af78bbbe00dd656290aea53af330
make: symbol lookup error: instdir/program/libfreebl3.so: undefined symbol: __asan_option_detect_stack_use_after_return
Starting from MSVC 14.0, the directory table layout of VC++ Runtime merge
module changed. As consequence, all MSI produced with newer compilers,
including MSVC 15.0 (aka VS 2017) are broken in term that the VC++
Runtime DLLs are installed in the wrong directory, e.g.: C:\System64.
According to the specification for merging merge module (msm), see:
"Authoring Merge Module Directory Tables": [1], custom action 51 (set
property) must be emitted for every directory name in the merge module
directory table if the directory name is starting with the standard
directory name.
Quoting it here:
"
When a predefined directory is included in a merge module, the merge
tool automatically adds a Custom Action Type 51 to the target database.
The merge module author must ensure that a CustomAction table is also
included. The CustomAction table may be empty, but this table is required
to exist in the target database and ensures that the modified predefined
directories are written to the correct locations. For example, when a
system directory is included in a merge module, the merge module author
must ensure that a Custom Action table exists.
Note that the matching algorithm for the generation of these type 51
custom actions only checks that the directory name begins with one of
the predefined SystemFolder properties. It does not verify that the
directory name exactly equals the directory property. Any directory
beginning with one of these standard folder names gets a type 51 custom
action, even if the rest of the name is not a GUID. Authors need to take
care that this does not generate false positive matches, and unintended
custom action generation, on derivative primary keys that begin with one
of the SystemFolder properties."
Rectify the problem by analyzing the directory table from the merge
module, checking whether the directory name starts with the standard
prefix name and if it is the case, emitting custom action 51 to set this
variable to the standard directory name.
Implementation details:
We use the existing facility for emitting the custom action table events
including referencing them in the corresponding sequence tables. Given
that the specification above doesn't mention what sequence table should
be referencing this emitted custom action, we reversed engineer this
information from WiX toolkit. Merging the VC++ CRT module with WiX
toolkit and investigating the resulting MSI with Orca MSI reader, reveals
that these sequence tables were referencing from these sequence tables:
* AdminExecuteSequence
* AdminUISequence
* AdvtExecuteSequence
* InstallExecuteSequence
* InstallUISequence
Replicate this behaviour here as well. Note, though, that custom actions
are generally not referenced in AdminUISequence and AdvtExecuteSequence
tables in LibreOffice MSI building tool chain.
Rendering of the custom action is achieved by programmatic emulation of
custom action in SCP module. Consider this similar SCP module based
action:
Name = "MigrateInstallPath";
Typ = "321";
Source = "shlxtmsi.dll";
Target = "MigrateInstallPath";
Inbinarytable = 1;
Assignment1 = ("InstallExecuteSequence", "", "CostInitialize");
Assignment2 = ("InstallUISequence", "", "CostInitialize");
We instantiate the following data structure to emit custom action
System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1:
Name = "System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1"
Typ = "51"
Source = "System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1"
Target = "[System64Folder]"
Styles = "NO_FILES"
Assignment1 = ("AdminExecuteSequence", "", "CostInitialize")
Assignment2 = ("InstallExecuteSequence", "", "CostInitialize")
Assignment3 = ("InstallUISequence", "", "CostInitialize")
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa367787%28v=vs.85%29.aspx
Change-Id: I2fbd37ff63298d99b2ba1b6afe6e875f56d8e378
Reviewed-on: https://gerrit.libreoffice.org/33366
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
This is a temporary fix, to allow testing of the new
windows IDE, without disturbing the existing one.
Change-Id: I4c59427541878acb6dd382af42deb7c0c952bcf9
PresenterSlideShowView::PaintInnerWindow has a mbIsForcedPaintPending flag
which is used to throw away the console canvas, but for other backends the
paint occurs at a much different time after a clear has a chance to get
triggered, while for gtk3 it happens as its being setup.
hack around this presenter console weirdness by skipping the initial
paint for this salsysobj case
Change-Id: If1b23600ef07241e52d92bd5eb38b9e90d9ed192
