Change-Id: I020d6f59751aef0bfb06667317ddcaf2965395d1

We now have hectares of empty space in the English ui on the right side because
the other tabs are wider than this one.

What to do with the extra space, leave it on the right, or consume it in some
other way ? I'm inclined to spread things around the available space. If we set
our elements to expand to consume it (but left align the spinbuttons within
their expanded space) then we get a page that looks very like the original.

I'm not entirely sure if I prefer it this way because it's genuinely more
pleasing to the eye, or because it's just familiar looking this way.

Change-Id: Iafe60713eb8c6f0bd1ecd70e3f288d52b453a247

Change-Id: Ic26237c2ecdc0728be6acb6d15e2d258bf093c74

Change-Id: I76db8e6e1460141ee4ef1bed10ea46c2b402b249

Change-Id: Icab9990a1e4bcbd709f63cb5ef24358441cced8d

Change-Id: I466b5e2232811af3fad2266c28e8c4475b77eb71

It appears I have a small bug in how size-groups and/or generic size-requests
work. It seems that margins should be part of the request, but I'm adding those
on after the request, not as part of the request. But we can workaround that by
putting a one element box around the elements with margins and put those boxes
into the size group instead. That way it works now, and will continue to work
after I change the request+margin logic

tristates are a pain, They are always set to "state unknown" on .ui load, while
in .src load they default to "state nocheck". So to be super sure that the
logic is unchanged set them explicitly initially in .cxx to "state nocheck"

restore accessibility relationship between tristate used as a label and the
labeled thing.

Change-Id: Ibf4879c3e9a4ecc4726896479377f51bf727b238

Conflicts:
	sw/UI_swriter.mk

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

Change-Id: Id84a5eaa4cea4c7cce9aa873c1a7c286e5d5cc92
Reviewed-on: https://gerrit.libreoffice.org/3349Reviewed-by: Michael Meeks <michael.meeks@suse.com>
Tested-by: Michael Meeks <michael.meeks@suse.com>

Change-Id: Ib87e3a5155176a6ce0531e04b08a2731a9c956a7
Reviewed-on: https://gerrit.libreoffice.org/3289Reviewed-by: Michael Meeks <michael.meeks@suse.com>
Tested-by: Michael Meeks <michael.meeks@suse.com>

Change-Id: I2b2099d8fc00062f67c42e73c4b8a17a689db89d
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>

Change-Id: Ia71f49eeca36ca65b319d47c6047fad310f5f248

Change-Id: Idf39b33efe4c7838f2669aec8773616416811d57

fix: While deleting any box from chart data provider, verify whether there are
any invalidate chart data sequence inside, if so, catch the exception and
remove it.

Patch By: Peng Chen
Found By: yanji
Review By: jsc

(cherry picked from commit a92e3539)

Change-Id: I239824e92d13e42b83674dbdeaeef053f1e6ea9a

The commit message of 0e5f2ea0? didn't
mention this, so I guess flipping over the default was just an accident.

Change-Id: I9078cc56a6064e3498b012848b860c7b414b37e6

When some import filter fix arrives in, and the submitter submits a test
file, but doesn't provide a matching testcase, we accept the patch, as
it's better than nothing. This script will search for such files,
providing kind of a TODO list for what testcases have to be implemented.

Change-Id: I713fe2f0aef4cbca66ba913baf54b7bd28ba2471

Change-Id: I6a7764637f6e5754e68ee6e4ab417224f542592d
Reviewed-on: https://gerrit.libreoffice.org/3348Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>

Change-Id: I42e5fe1f806712b2b912f945c164b0e239ecaa54

Change-Id: Ifa5091a5159d3832d3b8c8846eff57b6bfcf9854

Change-Id: I2b587946f094cd4e83f4148d6e3359452ec36bf6

Change-Id: I676c1305d997d756456245264e68676666f75c7e

Change-Id: Id8b9bec79e5673db738e16905eacd8e84cea89e1

Change-Id: Idac1c756faa47236e4ebc3c7400f7e4412f02a44

Need to pass the whole pixel buffer to CGBitmapContextCreate().

Change-Id: Iadac7dc3e63c29e5d0cc328b2e2a1f10824248a6

Change-Id: I04c715e88ee79aa639c10f2a39d303eecdbd3962

To properly handle subsetted BitmapDevices in the iOS vcl backend I
seem to need to know what the size of the full BitmapDevice is.

I wasted at least one day on desperate hacking and debugging, trying
to wrap my head around a misunderstanding of what a subsetted
BitmapDevice is. I thought it involved coordinate offsetting...

Change-Id: I83bf1a7d75ce192aaf21f1e408008e362fd6c6e6

Change-Id: Id9279b7e0dea2231db12997e571fe13ae240b914

Support cramming everything into one big merged library as well as
only the libraries depended upon by almost everything.

Change-Id: I69647037dc62840294ba670d5d6c172a4608bf3f

Change-Id: I5e44f15c236f5535fda1932c3206f4190834ae50

Change-Id: Ic362baf2204768d2e636b6fdd9199e8009c786d8

Change-Id: Ia86be34c6cfeab2a853305aa1568c384d7b4e2b9

Change-Id: Ib2efc547f0f1daf337cd15d78d76154b9863917f

i.e. use the same algorithm for assigning replacement ids for both get and set
exp fields.

Otherwise, consider for ex.
1. fields exists with ids of 1 and 2 in master document
2. a field exists with id of 1 in subdocument and must be reassigned a new
id to not collide with the pre existing master ids

In get orig algorithm assigned first unused slot of master to subdocument field
i.e. 0 unused in master, so subdocument:1 converted to master:0

In set orig algorithm sorted all used master slots and assigned largest used id
plus 1 (therefore unused) to subdocument field i.e. largest id used in master is
2, so subdocument:1 converted to master:3

so get can't find set and error's out with:
Error: Reference source not found

Change-Id: Ie8758dc22cf8deeeeff079532284e57eeaf4a9bd

Change-Id: I093d1a06c6771a22fb804b302d573dbfa72aaf86

Change-Id: Icb62af55a9d117627794852971a20542db51424c

Change-Id: Ied4e5cc9211b2a541006432d0b4d257f014249f4

Extremely annoying during debugging; and throwing / catching is not the
fastest operation under the sun...

Change-Id: Ic5604bb1c3ef77d1577c4ac611af44be6fea6533

The value returned by getScanlineStride() is always positive even if
internally the scanline stride is negative in the bottom-up case.

Change-Id: Iaf394639d1e5a27d64b83f75c1d715a9860e492e

Change-Id: I8a4a588287a90c6953b367bb02e075ea58f13a96

Change-Id: I6c37885823f14dcfbe750691dad27e094f46e66e