...it must implicitly be loaded by the UNO type manager classloader anyway (via
URE_MORE_JAVA_TYPES), so not explicitly mentioning it can help find problems
early should it /not/ already be loaded by the type manager classloader.

Change-Id: I35b4f2804b68a35682e93699840101a15317a096

Change-Id: I4610a2ff5bebd50dd2ee0020b575490c6c490968

Dropped XComponent from merged interface because noone is using it.

Change-Id: Id22c49e63679f42d86f617a919fdfd7cea4d5381

Change-Id: Id195be7968ab256e44271cad00fa8b5cac8698b4

Change-Id: If15cd2ac23bf76aa79ee8134ee0fb97c64d747c3

Change-Id: Ic59060818bf02a402610613a6bc97c5969a5c461

Change-Id: I4500ba71abeba5fe8293cea22b10fd910e46059f
Reviewed-on: https://gerrit.libreoffice.org/3816Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Conflicts:
	Repository.mk
	scp2/Module_scp2.mk
	solenv/gbuild/Helper.mk

Change-Id: I37570787815d85d30eed3b5291e1e4450e5ffd51

Change-Id: Id986bc7f9f09902dfda849bc86f9c48ccb0f30c3

Change-Id: I4c13d1cd4b7490a0b4db8f0dd40d823a5906c8aa

Change-Id: I2fb97a1422ed82c79b7babff793dba700eba2369

It is not possible to create wiki pages with URLs that have %2F in
them. Help URLs contain %2F, when invoked from dialogs that are
based on .ui files, it seems this is the new HID syntax.

For example for Zoom dialog LibreOffice used to call
http://help.libreoffice.org/simpress/cui%2Fui%2Fzoomdialog%2Fzoomsb
and it did not work. Now it calls
http://help.libreoffice.org/simpress/cui/ui/zoomdialog/zoomsb
and it works.

Change-Id: I163cf8ec3b69f31eadbbd9085d2180839fe91e07

Change-Id: I7c06fe72789eb6108b13eefaca3ff9c9b3416f31

Change-Id: I985b3373edcd0bfc151adfa92b79a6b5080d22ad
Reviewed-on: https://gerrit.libreoffice.org/3805Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>

Project: translations  e06e924e1a2d2497cea1f282ab5381ee78f0b05e

Change-Id: I85a7dd4454233141e1cefc04cf30f999babf6ae7

No idea what the nonsense about cargo-cult in the previous two commits
was about though.

Change-Id: I97a7a39ad431e5ab9eab4de6de2b08d4d6889307

Project: translations  3b967bbce7fae6b042bbbe5c2bf9fad14941192f

Seems with the extensive drawinglayer rework, we now get bitmap
fills rendered via clip polygon and subsequent bitmap tiles. To
get the true bound rect of the current metaaction, clip it against
outdev's clip region bounds (as some reasonably cheap best-effort
approximation).

Change-Id: I4ecf04e2d94da21acc97362a1a65a965c7176077

... for Package_generated removal

Change-Id: I14d8da088964224b68fba03e920eeb5a2d19f9f5

Hopefully a better choice for defaults will minimise the chance of a bad colour
combination for notetext and notebackground colours when one colour ( more than
likely the notetext colour ) is gleaned from some default ( e.g. like a system
 tooltip colour ). We change the choice from system helptext ( fg & bg ) colours
and use Libreoffice default font and default note background colours instead.
The rationale here being that even in the normal scenario it seems with modern
excel documents the note background colour is a 'real' colour and not an index
( therefore the colour selection from some predefined colour doesn't happen )
But the note text colour is generally a colour index ( therefore a colour is
selected from defaults ). In say gnome3 the default tooltip colour is now white
 and a really bad contrast to the normal background colour for a note. I changed
the code here to use the colours from libreoffice given that the default colours
more or less match Excel default colours ( which will be by far the most
frequently ) used combination

Change-Id: I2ae38a44e0cbf201beb3b7d18a89f5ebdd644f8c

...just like it was implicitly exempted while it was still part of juh.jar.
(The true fix should be to remove this smoketest-support code from general
installation sets, but that is left as an exercise for another day.)

Change-Id: Ia8bb07795facef5f344e3e53c3901f229725d1af

Change-Id: I082956036843b6a88e3e1db3d799985599ae2980

This one is ugly, the Yacc generated header is used in lots of places;
the dependencies are already right because using the header requires
using the dbtools library which builds the YaccTarget, so just yet
another include path has to be added.

Change-Id: I031fde80ac326551d4719533305b1ae35351ca43

Change-Id: Iab5eb4fbfecea905f4eeb9f1b1f503c1908dadc8

Change-Id: I3791f7f513246faaeb76f9209c08008c78a38619

Instead include generated headers directly from workdir.

Change-Id: I9d2bcc07175d2bbc16d3cc548c2245e7a4fb0c65

...into a new smoketest.jar, so that URE juh.jar no longer depends on non-URE
unoil.jar.

Change-Id: I8937c78d8af6e2f82ada5dd80c322f8bca5ec2f5

- Mapping LO default style to Word "Normal" style for docx output used a
  hard coded style name, so it broke when LO's default style was renamed
  in 4.0 (plus it would never have worked for non-English languages)
- This renaming did not cater for nameclashes, leading to fdo#63603
- Similar renaming when importing doc styles did cater for nameclashes,
  but had a minor bug in that

Change-Id: Id23f3021c6507b474c16e93abf43ba748606ebc7
Reviewed-on: https://gerrit.libreoffice.org/3743Reviewed-by: Luboš Luňák <l.lunak@suse.cz>
Tested-by: Luboš Luňák <l.lunak@suse.cz>

Project: help  c599d2dde1df55d8d743d4eaf3521dbb4db10361

The motivation is that if -- after fixing a crash -- the document looks
OK, then all the paperwork in the ooxmlimport isn't necessary, just drop
in the file to qa/core/data/ooxml/pass/, and we're done.

Change-Id: I2287189bd3c49c5e53489f9d89a6341685359b33

Project: help  87300967302507220e9a33e1f48d73779c584791

Change-Id: I27ffb8f1bddc0a41d76a8b6d441e10e9a71ff10f

...from 43debfae "General cleanup of
OfficeBeans," as this is a stable interface that should not be broken airily.

Change-Id: I931a611341a1b29346d134c11ecf886fe7767836

Change-Id: If1c4278fa02a74b040af444eb6ca89209daea13a

(should hopefully fix tinderbox breakage)

Change-Id: I460b782b1bbf212a4f535960f82b2a2843f6fe74

Change-Id: I4d8b1b527d5099781a36cc1265318c167205340e

Change-Id: I9fd616930eb0b336ce89e97bc333f19d4cf449ae

Project: dictionaries  6434e14f6601183d8b95f9d4f9a544525b3dc5c9