Change-Id: If442340bd718932ace4f0919ac274d81faa07c60
Reviewed-on: https://gerrit.libreoffice.org/72037
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I7b4d2e5e611935284e2902b0089950768dfb7717
Reviewed-on: https://gerrit.libreoffice.org/72036
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Such ID is not meant to be presented to the user, but to be an ID
which is stable over application development. Typically, this is
the gtkbuilder ID. Such an ID can then be used to identify a given
well-known accessible object independently from the current locale,
user-visible labelling, or dialog structure. This can then be used
for tailored screen reading (e.g. automatically announcing the
content of a well-known object), or for automatic regression testing
(to check the behavior of well-known objects). Uniqueness within
the window is thus desirable when returning a non-empty string.

This adds XAccessibleXContext2 to augment XAccessibleXContext with
getAccessibleId().  The VCL implementation just takes Window::get_id(),
i.e. the gtkbuilder id, which is enough for most use cases for now.

atk_object_wrapper_new then passes it to
atk_object_set_accessible_id() for AT-SPI technologies to pick it up.

Change-Id: Iea0ad08d036e539dbcfec1a9be026c8da8d17357
Reviewed-on: https://gerrit.libreoffice.org/71743Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins

Change-Id: I22d811a89f0e024e99cccffc0c05b373e2820140
Reviewed-on: https://gerrit.libreoffice.org/72022
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>

Using g_main_loop_run here appears to be inherently necessary for the
g_file_mount_enclosing_volume/g_file_mount_enclosing_volume_finish protocol, but
has at least two problems:  For one, it temporarily drops the SolarMutex (if it
was held by the current thread), causing the usual integrity issues caused by an
inner stack frame temporarily releasing the SolarMutex that is held by some
unsuspecting caller.  This is an inherent problem of our broken SolarMutex
design, and this change can't do much about it.

But for another, at least with GTK-based VCL backends, it also means that the
current thread can start to execute VCL events at "unexpected" times from within
this g_main_loop_run (e.g., paint events, as in the backtraces linked from
tdf#124962).  While handling of VCL events is necessary when a callback to
ooo_mount_operation_ask_password happens and it actually pops up a dialog
prompting the user for credentials, such handling of VCL events is completely
unwanted when no such dialog is popped up (e.g., when the given server is
unreachable anyway, as is the case in tdf#124962).

So, to shrink the problematic window of time in which VCL events may get handled
from within the gio MountOperation, use a dedicated GMainContext for the gio
GMainLoop (so that it only handles events related to the mount operation), and
only temporarily put back in place the original GMainContext during
ooo_mount_operation_ask_password (so that VCL events will get handled as
necessary when a dialog is actually popped up).

Change-Id: Ie410f23778045b1adf98579bb34ce38d0f8f3320
Reviewed-on: https://gerrit.libreoffice.org/72026
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

Change-Id: I8dc5a6ef84f43bad0bee26592b3a8e95c58e6f22
Reviewed-on: https://gerrit.libreoffice.org/72027
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I1fa8248efa16a718f273f20620281737b0da455d
Reviewed-on: https://gerrit.libreoffice.org/72024
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

with dynamic columns

Change-Id: I1f2ed918932066d8b0def57568f5dc23be3605e4
Reviewed-on: https://gerrit.libreoffice.org/72028
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Doxygen used to allow this but there was a regression, which is
apparently not being fixed:
https://github.com/doxygen/doxygen/issues/6304

Change-Id: I7602236522a56c30a2249bd8065796b3c6458704
Reviewed-on: https://gerrit.libreoffice.org/70377Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Michael Stahl <Michael.Stahl@cib.de>

Change-Id: Iafbb69a405a3c9ee8d0ae7dbe8a24a75d237519d
Reviewed-on: https://gerrit.libreoffice.org/71924
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

Change-Id: I337c0f567112f95e2a1d762e511d5b632dd2892f
Reviewed-on: https://gerrit.libreoffice.org/71997
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

As seen in tools/source/misc/cpuid.cxx

Change-Id: Ic596cca387efc1c310f65cbed141946be0742371
Reviewed-on: https://gerrit.libreoffice.org/71885
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

As seen in configmgr/source/modifications.hxx and
configmgr/source/partial.hxx
this replacement is not needed

Change-Id: I6a8d7bc37779f305fccb5d3c7df22fba4a4f73d0
Reviewed-on: https://gerrit.libreoffice.org/72013
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

This avoids the preprocessing step normally done by ccache (see
ccache docs), which speeds up the build.
This way there may be incorrect ccache hits if a system header
(found using -isystem) changes, but that should be rare and such
headers generally should be backwards compatible, so the chance
of an actual breakage should be very low.
The patch also adds --enable-ccache=nodepend to allow enabling ccache
without the depend mode.

https://lists.freedesktop.org/archives/libreoffice/2019-May/082684.html

Change-Id: Id69ca43988a016a917beb75927b39d8bde719aa7
Reviewed-on: https://gerrit.libreoffice.org/71629
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

So that it works out of the box automagically.

Change-Id: I0a6c93824233eef6ce25c44762ec40770ec5110f
Reviewed-on: https://gerrit.libreoffice.org/71628
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

It a) looked a bit silly to use .gch even with MSVC, b) allows to build
something with Clang and GCC without them trying to use each other's PCH
file, c) is nitpicking, yeah.

Change-Id: I478beeb6aab6378cbdcc6ea75aa2e3ff2bcf6f87
Reviewed-on: https://gerrit.libreoffice.org/71582
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

Plus some build fixes triggered by this.

Change-Id: I59b21def706598ceffd45ae5b1f0262ec9c1ad50
Reviewed-on: https://gerrit.libreoffice.org/71581
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

There are now 4 levels of PCH support, the previous 'full' level
adding to PCH whatever the update_pch script finds useful,
and new levels 'system', which adds only external headers,
'base', which is 'system' and LO basic headers (sal, osl, rtl, vcl)
and 'normal', which is 'full' without headers from the module
built itself.

With Clang/GCC even 'system' still saves some time (10-15%) and since external
headers should rarely if even change, it should be without most
of the disadvantages of PCH. And even 'base' should be pretty easy
to use, as those headers should be rarely changed while developing,
thus avoiding the need for massive rebuilds. Using 'normal' or 'full'
does not seem to be worth it with Clang or GCC, but with MSVC that still
makes a difference, so keep(?) 'full' the default there.

The update_pch script unfortunately does not include as many system
headers as it could, since it includes only what is directly included
by the .cxx, but not what's included indirectly by .hxx files.

https://lists.freedesktop.org/archives/libreoffice/2019-May/082685.html

Change-Id: If83a07a1fc9b77d0134502b0d89348944f82806b
Reviewed-on: https://gerrit.libreoffice.org/71580
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

config_xxx.h headers are not system headers, and some module headers
as such helpids.h or scdllapi.h are neither.

Change-Id: I7ae1a3f1ada43de88eefe34c60e19f7ac703769d
Reviewed-on: https://gerrit.libreoffice.org/71579
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

Change-Id: I52ef8e81cb3899cc8d2b8729bd55ee98a0a1c77b
Reviewed-on: https://gerrit.libreoffice.org/71565
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

The problem is that the SwTabFrame and SwRowFrame that are being
iterated are deleted:

 7 SwFrame::DestroyFrame(SwFrame*) (pFrame=0x79052c0) at sw/source/core/layout/ssfrm.cxx:386
 8 SwTabFrame::RemoveFollowFlowLine() (this=0x5bf07d0) at sw/source/core/layout/tabfrm.cxx:907
 9 SwTabFrame::MakeAll(OutputDevice*) (this=0x5bf07d0) at sw/source/core/layout/tabfrm.cxx:1839
10 SwFrame::PrepareMake(OutputDevice*) (this=0x5bf07d0) at sw/source/core/layout/calcmove.cxx:344
11 SwFrame::Calc(OutputDevice*) const (this=0x5bf07d0) at sw/source/core/layout/trvlfrm.cxx:1790
12 SwFrame::PrepareMake(OutputDevice*) (this=0x603a570) at sw/source/core/layout/calcmove.cxx:247
13 SwFrame::Calc(OutputDevice*) const (this=0x603a570) at sw/source/core/layout/trvlfrm.cxx:1790
14 SwFrame::PrepareMake(OutputDevice*) (this=0x5daf120) at sw/source/core/layout/calcmove.cxx:247
15 SwFrame::Calc(OutputDevice*) const (this=0x5daf120) at sw/source/core/layout/trvlfrm.cxx:1790
16 SwFrame::PrepareMake(OutputDevice*) (this=0x6005ca0) at sw/source/core/layout/calcmove.cxx:247
17 SwFrame::Calc(OutputDevice*) const (this=0x6005ca0) at sw/source/core/layout/trvlfrm.cxx:1790
18 SwFrame::MakePos() (this=0x6094330) at sw/source/core/layout/calcmove.cxx:490
19 SwTextFrame::MakePos() (this=0x6094330) at sw/source/core/text/frmform.cxx:343
20 SwContentFrame::MakeAll(OutputDevice*) (this=0x6094330) at sw/source/core/layout/calcmove.cxx:1346
21 SwFrame::OptPrepareMake() (this=0x6094330) at sw/source/core/layout/calcmove.cxx:368
22 SwFrame::OptCalc() const (this=0x6094330) at sw/source/core/inc/frame.hxx:1060
23 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7ffc6da48350, pLay=0x8a349c0, bAddRect=false) at sw/source/core/layout/layact.cxx:1362
24 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7ffc6da48350, pLay=0x79052c0, bAddRect=false) at sw/source/core/layout/layact.cxx:1357
25 SwLayAction::FormatLayoutTab(SwTabFrame*, bool) (this=0x7ffc6da48350, pTab=0x7a9c300, bAddRect=false) at sw/source/core/layout/layact.cxx:1569
26 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7ffc6da48350, pLay=0x7c30300, bAddRect=true) at sw/source/core/layout/layact.cxx:1354
27 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7ffc6da48350, pLay=0x79e1780, bAddRect=true) at sw/source/core/layout/layact.cxx:1357
28 SwLayAction::InternalAction(OutputDevice*) (this=0x7ffc6da48350) at sw/source/core/layout/layact.cxx:546

They are deleted because the last SwTextFrame was moved via MoveBwd() to
the previous page, and is formatted there.
(regression from commit 18765b9f)

Prevent this via:

* delete-guard for the SwRowFrame - causing RemoveFollowFlowLine() to
  return early (also, let it return false, so the Join() isn't even
  called, although that doesn't make a difference in practice because
  of the next item:)

* join-guard for the SwTabFrame - otherwise tabfrm.cxx:2199 will Join()
  it anyway

This means that when the page with the follow-frame is done formatting,
the empty SwTabFrame with no SwTextFrame in it will remain.  Fortunately
this is not a problem, because due to the moving, the previous page will
be invalid and layact.cxx:613 will iterate to the previous page and
format it again; then tabfrm:2199 of the master SwTabFrame will detect
that the follow SwTabFrame is empty and Join() it.

Change-Id: I2cca89d63b81e7d4909319fa4feab2f5d67a6ff3
Reviewed-on: https://gerrit.libreoffice.org/71996
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

For one, it seems this was the intention already since commit
85c70f37 (CWS-TOOLING: integrate CWS
aw063, 2009-03-04): "suppress AntiAliasing for pure horizontal or
vertical lines".

For another, this fixes the TileCacheTests::testTileWireIDHandling()
testcase in online.git, which assumes that the indicators at the corners
of the Writer body frame (paragraph marks hidden / default case) can be
painted multiple times, producing pixel-by-pixel matching results. But
in reality AA breaks that assumption, and we know these indicators are
never diagonal lines.

Change-Id: Ib74f823165799991296b64cee58ec106dbdcedcf
Reviewed-on: https://gerrit.libreoffice.org/72000Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins

2nd attempt to fix the bug described in commit 00221089 ("Qt5
IM allow committing empty strings") and various siblings of it.
This also reverts it.

What I see is calls with "all-empty" events (preedit, commit and
replacementLength() == 0; no QInputMethodEvent::Attribute), some
from QIBusPlatformInputContext::updatePreeditText.

There are various Writer document edit states with (selected)
text, undo, cursor position and focus changes to other windows via
Ctrl+Tab, which will result in inputMethodEvent calls totally in
contrast to the expected text state, all somehow always related to
all-empty events. They currently result in wrongly deleted
selected text, change of selection, cursor movement or general
change of text from old preedit. Most time on focus out / window
change, some times at first meta-key press after focus in.

This patch tries hard not to corrupt Writers edit state with these
all-empty events. No idea if this is some bug on LO's qt5 side or
expected, but KDE kate and VCL gtk3 and gen work fine, so I assume
Qt's behaviour is correct. FWIW gtk3 also does some extended IM
handling with focus, so probably this is the Qt equivalent of it.
But then I couldn't find some eqivalent code in Qt's source code.
I actually expected an even more complex solution (if this really
fixes all cases).

Works for a multitude of tests I tried to come up with, but is
quite probably not the final fix to this, as qt5 current doesn't
handle replacementStart() and replacementLength() at all.
Also never saw a call to Qt5Frame::EndExtTextInput.

Change-Id: I4210e0588041cfb4d80dbdfdb937e430a5f7cbfb
Reviewed-on: https://gerrit.libreoffice.org/71988
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

Similar to bug 105625, the cursor should be considered outside
of a fieldmark when it is at the start. A delete at the start would
normally delete the entire form field, but in this case the section
is supposed to be protected, so deleting should be forbidden.

This atStart situation is already looked for when the document is
not protected. However, when the section is already protected, then
a different code path is followed, and there the start position
was ignored and thus became an editable part of the page,
allowing the user to easily delete the field by mistake.

LO6.2's commit 63ec2e8d
accurately identfied that this is in a protected section,
and so exposed this missing scenario.

Related idea: Also added a unit test to ensure that Protect_Form
keeps protecting the formfields as well.
A test document in the bug report, containing a combobox and checkbox,
confirms that this fix is good for all three types of fieldmarks.

Change-Id: Ida08163f3376e55c620d6670da160832e79cd252
Reviewed-on: https://gerrit.libreoffice.org/71927
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>

Synchronize sub menu Tools > Macros by adding "Edit Macros" across the
different applications menus.

Change-Id: I16185034955d889afe8a508a3522bb0a63f29545
Reviewed-on: https://gerrit.libreoffice.org/71827Reviewed-by: Heiko Tietze <tietze.heiko@gmail.com>
Tested-by: andreas_kainz <kainz.a@gmail.com>

Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.

Change-Id: I89c77656ea4021cb16bd122cb1dd1cd803390c3d
Reviewed-on: https://gerrit.libreoffice.org/71765
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

Change-Id: Ibe4ef82cf719afd008f1be23ed4a0e953c61d73f
Reviewed-on: https://gerrit.libreoffice.org/72010
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

Change-Id: I2b5827c3f6fd7630655d4658844792462f80767e
Reviewed-on: https://gerrit.libreoffice.org/72016
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

Use range-based loops

Change-Id: I4d3be75bb83c74267b9dec6f1dcdc105c292be9d
Reviewed-on: https://gerrit.libreoffice.org/72011
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I05c627f590e7794c1ba11b66021dc30aa3285eb0
Reviewed-on: https://gerrit.libreoffice.org/71941
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: If7f51a657606da8aea4bcf01f13468c6ac2086a8
Reviewed-on: https://gerrit.libreoffice.org/71901
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

...in preparation for another change using a top-level namespace ucb

Change-Id: I3a92d64806bc570bdfd4fe06e672cb6ce2049e7e
Reviewed-on: https://gerrit.libreoffice.org/71987
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

Change-Id: I0c594c232a3004c83a33f0948593850dd924caad
Reviewed-on: https://gerrit.libreoffice.org/72020Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>

This is intended to replace the ImplPixelFormat in macOS and
OpenGL backends, which are duplicated. It'll also come in
handy for other situations in the future.

Also ImplPixelFormat4 (4-bit Palette) in the macOS backend
doesn't work and never has worked correctly (bug at writing).
This fact was discovered while testing the ScanlineTranformer,
which was based on the ImplPixelFormat* code.

Change-Id: I96a172bd61c2cc116ab3e8b9f47f23f945243e96
Reviewed-on: https://gerrit.libreoffice.org/71992
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

Change-Id: I4b4fc85024d64f94197bd0fd25ed8ba0ada004ba
Signed-off-by: Adrien Ollier <adr.ollier@hotmail.fr>
Reviewed-on: https://gerrit.libreoffice.org/71807
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

Change-Id: I88a32792c19a8d16c400dd2a189c4941149ff941
Reviewed-on: https://gerrit.libreoffice.org/72019
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

Change-Id: I77133378411c573dd1075d40c7e113b305b3dbba
Reviewed-on: https://gerrit.libreoffice.org/72017
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

...after 7764439f "WidgetDefinition: add
'action' state for the PushButton" introduced code that downcasts that
suspicious ImplControlValue to a PushButtonValue

Change-Id: I3ed24cc4a862d53ad5b6e95b4707bab7947ce7ba
Reviewed-on: https://gerrit.libreoffice.org/71998Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins

Change-Id: Idfefe7598df0b2e382be84aa5bfc8b60201768a7
Reviewed-on: https://gerrit.libreoffice.org/71991
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

e.g fdo58094-1.mml

since...

commit 13894996
Date:   Sat May 4 21:46:31 2019 +0200

    handle empty Rectangle better in starmath

Change-Id: I01d11352b8bc9f6dcf6d6565fa41b84d549f620f
Reviewed-on: https://gerrit.libreoffice.org/71963
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>