Change-Id: I8da4395cefe6bb542ab7cac2a849ec587a63f37c
Reviewed-on: https://gerrit.libreoffice.org/33814Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>

the path in gbuildparse changed, so this patch re-adapt this
2 IDE integration

Change-Id: I5f7a679b8b12eac6f44030a33713ff19327b9d1a
Reviewed-on: https://gerrit.libreoffice.org/33815Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>

Change-Id: I9eb700a0977d13dbca41962eeb74b33f80ee7ef1
Reviewed-on: https://gerrit.libreoffice.org/33820Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>

Change-Id: I41a5636aa6b87ae26a615c0e267dae64e12a6c6b
Reviewed-on: https://gerrit.libreoffice.org/33639Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>

Change-Id: Id81bcf7d9c93080116333be48e666e0cf10c6508
Reviewed-on: https://gerrit.libreoffice.org/33643Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>

Change-Id: Ic459eefde02037c0aa615044003abaf03e48f9e3
Reviewed-on: https://gerrit.libreoffice.org/33819Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>

The test case itself is derived from tdf#43831.

Change-Id: Ifd847e84b84b02c1eb74572303af729c30c4f380
Reviewed-on: https://gerrit.libreoffice.org/33818Reviewed-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/33817Tested-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/33816Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>

Change-Id: I5acc6ce95a3dc7fe6e23088ef2ec9c6a93d32670

Change-Id: I7b1c9722e300585603ce54610d7ef20425a4e634
Reviewed-on: https://gerrit.libreoffice.org/33797Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Takeshi Abe <tabe@fixedpoint.jp>

Previously, the fieldmarks couldn't be removed with backspace or
deletee when cursor was right/left to them.

After commits f72b866c and
c34fc452, 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/33812Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

(regression from f3a90d13)

Change-Id: I54e3f06a74b2ac715061b5da54ac4db2b0a1010a

Change-Id: Ie34f030abad75317b8bd813386e6bbf9439a3d1c
Reviewed-on: https://gerrit.libreoffice.org/33810Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>

Change-Id: I3f602b881477653f51025fce72d22a0499e7f077
Reviewed-on: https://gerrit.libreoffice.org/33806Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>

Change-Id: I26d49db0207b3f4f64aa9698da4cf3567d195834
Reviewed-on: https://gerrit.libreoffice.org/33800Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>

Change-Id: I8a3b138c051d3cddf25855a635262311669bdddc
Reviewed-on: https://gerrit.libreoffice.org/33798Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.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

Change-Id: I4a34f03fdab4626bdbf9b254986b0953ecfdffa7

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/33366Tested-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

Change-Id: I3b57086349d039087dc9395f7af63f8e8fbf1bab

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

Sometimes gbuildtojson does not get rebuild, and thus
delivers unexpected json files (old keys)

Change-Id: Ib4bab170ed5a2ab5c112d19af144f2551e608278

Change-Id: Ie13a5e04207475794fef75c568786f37eb2c406f
Reviewed-on: https://gerrit.libreoffice.org/33230Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Heiko Tietze <tietze.heiko@googlemail.com>
Reviewed-by: Akshay Deep <akshaydeepiitr@gmail.com>

Change-Id: I89c809a220efc006d3b5b0675c050ff07cb2dbfe
Reviewed-on: https://gerrit.libreoffice.org/33380Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Change-Id: I287f166291a905c9f4d166bf07c09de93184bf87

Change-Id: I9dc03760831f3f1ff433c67abde95060d533ea14

Change-Id: Iffab8e3d8ecaad835d5f0cce68ede4eaea1547a4

This reverts commit a4d5d69e.

Once is enough.

Change-Id: Ie16af2d0943cec6374307e9afb09cd47ed6d7043

Change-Id: I8b7611d6fdc55fc8cd9551e129a2e03e58682229

Change-Id: I53699ef386dad99b38559defe985057492a5df76

Project: help  732cd669a0f593eeaacaa4f67bce5947a431c0c1

Adapt hids after popupmenu xml conversion

Change-Id: Icf119499f75a838ec6159ae19c33e16be9967da5

Change-Id: If59ecb4ea92d9daf423aef870e79248f5bc93e6d

Change-Id: Ifcce63b975fb7c4ac7e7545e3eadcc6f7f12e466

Change-Id: I6e68a6728eed108c7670ebef6073394de3f53e6b

Change-Id: Ie261d5412c510c045b4d93a6bf1a3d4cf4371897

Change-Id: I39d443e582a6e82947f9c833b157f137a082a358

Change-Id: I8bd752814994fedac17fe0d002b415902c276b20