Change-Id: Ie6ae2150e1f011e17034abcace18c5967b4dacf5
Reviewed-on: https://gerrit.libreoffice.org/2023Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Peter Foley <pefoley2@verizon.net>

Thank you Kohei for the better patch you proposed to me

Change-Id: I145aaf6fd139a29373c41cc2ea81dadc9160f0fe

Change-Id: I54d7372bade5ac067a781956d987409008de0b2b

Change-Id: Ifb760fd0a0fa1430b77838a0340cc0956a0201a7
Reviewed-on: https://gerrit.libreoffice.org/2029Reviewed-by: Thorsten Behrens <tbehrens@suse.com>
Tested-by: Thorsten Behrens <tbehrens@suse.com>

In the evolution address book where we have real column names of e.g.
first_name, second_name and city. On parsing via
OSQLParseTreeIterator::appendColumns that creates some labels using those real
names but the evo XResultSet gives them proper labels of First Name, Second
Name and City the munge means that here we have e.g. just "City" as a label
because it matches, while the others don't

The symptoms are to load the evolocal.odb and of the 128 columns column 5 is
repeated until 128

This is all a horrible confusing mess. It seems safest to catch the
mismatch of column counts and throw away the partial list and force
a generate of a full list.

Change-Id: I1d6e2a282bdd43acac63c366eb2a9d029aa17878

because we identified the addressbook by their user name continue to do that for evo >= 3.6
even though that's got a better uid we could use. This way we can reuse the automatic
mapping of fields in writer (search for Personal in officecfg) for mail merge

Change-Id: I42e1d7aac9dd9640f0bb38e9224a393ac81481a1

Change-Id: Ieffe1a374f3f94991ca63b6ccfbfb7bdc43255d6

Change-Id: I04d2a4d7d1520567dd0eb929ffb5d9fa53d35dd4

Project: help  331b8c672849fc422086552abb3723c82a2fa832

I hope that LO will handle potential incompatible menu or toolbar
entrie. But this problem happens also when updating between minor
versions.

Change-Id: I5be9b4e036464806d04eb6e0e9808b503f288498

Otherwise there's an error message e.g. during a clean build.

Change-Id: I42efd08e014a4ebe25cfd1a497f622e5ea5c39ad

CLANGFORCE was the first in the makefile after
c6ffe176 and therefore the default

Change-Id: Id3b86a1ea2c27479067f7f55a977da3e6e8a2dfb

Change-Id: Iaa91d3b1ab47e02edc69c2b9abdb33ae097571cb

Change-Id: Icac851be692837873b177b4bd9a7c47d3d785702

I had a conversation with some UX-members, they all agree the close button needs to be on the far most left of the findbar.

Change-Id: I3c13df4821f3f4f86fec02fa5427b2277fa10c19
Reviewed-on: https://gerrit.libreoffice.org/2025Reviewed-by: Jan Holesovsky <kendy@suse.cz>
Tested-by: Jan Holesovsky <kendy@suse.cz>

This reverts commit 3c71fa1e.  There are cases
(like failure to install a per-user extension during upgrade), where the user
may want to still see the broken extension in the Extension Manager, instead of
it "disappearing completely."  A better fix would be to roll back registration
of the broken extension completely, so that "unopkg list" would not list the
first half of its parts as "is registered: yes" and the second half as "is
registered: no."

See http://code.google.com/p/android-coverflow/source/browse/LICENCE.txt

Change-Id: I29cd2f9115f9c711dc07d8efbe89e42bedab040f

With gdb 7.5.1 the dynamic_cast may cause "Couldn't determine value's
most derived type for dynamic_cast", which isn't helpful either.
So just print the current XInterface value in case the cast fails.

Change-Id: I453b1a8eecbb056853293280195f6475f8852f2b

... throws IndexOutOfBoundsException, since it's not supposed to happen.

Change-Id: I876e6cede88f86d12543d3ce65e1b0a0ca5389a7

It was only exported in an MSVC build before, which is a regression from
the gbuild conversion (c322d509).

Change-Id: I46783dc5fff5383bad8f8292c615ba8daa071cf9

Change-Id: I8ffa5ba2bbbd15533ea5097e0b018be3766ecc8b

This problem can be reproduced with the bugdoc from fdo#60234, by
dragging and dropping the lower left drawing object.
The ATK bridge is notified of the change, and updates its list of
children by calling getAccessibleChildCount() and then
getAccessibleChild() in a loop.  Unfortunately the count returned does
not match the available children (the difference is the object that is
being dragged).  The implementations in
SwAccessibleFrame::GetChildCount() and SwAccessibleFrame::GetChild()
use slightly different iterators for the SwPageFrm, and the
SwAccessibleChildMap one is implemented as a std::map, using the OrdNum
of the drawing object as a key.  On the dragged object, that OrdNum has
been reset to 0 in RemoveFlyFromPage, but it is still in the pSortedObjs
of the SwPageFrm, and so it is not inserted into the map, and iteration
over the map is missing one element.

149     return _SwAccessibleChildMap::insert( aEntry );
Value returned is $22 = {first = {first = {eLayerId =
SwAccessibleChildMapKey::HELL, nOrdNum = 0}, second = ...}, second = false}

Fix this by removing the object from pSortedObjs before disposing
the a11y frames.

Change-Id: I4e4bb37759382e32150cff6def02d80a55e4a702

Change-Id: Id054eb611fe86fdaaf1bba8d1e85342a3cc0e146

Change-Id: I2086b724a6787838b9dd61c78d6943a1efa27a19

A cell when modified ( e.g. content deleted ) should have its row height
recalculated when the optimalheight attribute for that row is set.

Also tweaked the test framework to allow read/write files to be loaded, this
allows functions that modify the document content to actually work as intended

Change-Id: Ia929a194a96f5c8b870f9a49d1e27d0c34ba9c91

With Change-Id I7cb1cf29bcae59ef26cf3bf0c2b3dd028eb8f878, this code
gets run on every onCreate, thus adding activities on top of
existing ones. Seems FragmentManager lifetime is a bit decoupled
from Activity

Change-Id: Icc1dc86ef91257ce734ee00fed83e909ddf52dc8

Change-Id: I05efe58e38b7c2183ecc733b6db45ec6fa04cab7

Change-Id: Id989bcf78fc10eb29e9afd89c71e2deb2b98b4d3

Change-Id: I6542470c2d4b27de25e263651e25baf85c7d018d

Change-Id: Ib5d8ea83e37ab1e3c5a1ad4dc9870d3d5a2d8779

Change-Id: I806453efbc5f7bb18f34593c350b05d74a0bc23b

Change-Id: I2aa68c7bf265943e3d015a069fab461882c81554

Change-Id: I36bab07a127f90f651f3db67831a37bbb78900ce

Change-Id: Id350532d88ba7c9a54d5440748f5ff456ae58722

Change-Id: I6a28c7285786c08cd52cee59f2babcfa336a00d5

Never mind. Seems to be necessary after all.

This reverts commit 0db854a9.

Change-Id: I945556ecc2cb2f2f2c2636afbf7c02469d74b4c1

Project: help  ba8241b6b1ddd1db8f597152b440c947a8702cd6

Change-Id: I9ee25faa57397ec2d0e7e9bb77aabade4404e32d

Change-Id: Idc31ebc5bb2d11345f68b7275b7fc4d335b633c1