Change-Id: I64d559603bff0d618dce72927566531296984d3c
Reviewed-on: https://gerrit.libreoffice.org/3823Reviewed-by: Noel Power <noel.power@suse.com>
Tested-by: Noel Power <noel.power@suse.com>

Change-Id: I8a2c079a60cc06ca82d9f516cf009359a0c083a7
Reviewed-on: https://gerrit.libreoffice.org/3819Reviewed-by: Noel Power <noel.power@suse.com>
Tested-by: Noel Power <noel.power@suse.com>

Use the same GUID in the file dialog for the FILESAVE_AUTOEXTENSION
case as for the FILESAVE_AUTOEXTENSION_SELECTION case. The former is
used when exporting to PDF. Exactly why using one GUID for the dialog
causes it to use the default folder as set by SetFolder(), and the
other not, I have no idea. Are the GUIDs we use arbitrary (and unique
to the OOo/LO codebase), or does either of them, or both, have some
magic meaning to Windows?

FILESAVE_AUTOEXTENSION is also used in other cases than exporting to
PDF. It remains to be seen whether this change will cause noticeable
behaviour change interpreted as a harmful regression. Or whether the
change of default folder for PDF export will do that, for that matter.

Change-Id: I135e4b2b2bc4dc70670919fb478196e27b55ac79

Change-Id: I91c1d505ef0b0eb442bf76e4da66c95fa0e1bb2d
Reviewed-on: https://gerrit.libreoffice.org/3818Reviewed-by: Noel Power <noel.power@suse.com>
Tested-by: Noel Power <noel.power@suse.com>

...to revert a206bc22 "avoid warnings about
deprecated decls. from glib2" in my Fedora 18 environment, it /does/ fail now
post 98ba9ca0 "Revert 'avoid warnings about
deprecated decls. from glib2.'"

Change-Id: I42d118c06665c976a26a2dbfedc31ca4c8bcf0cc

This reverts commit a206bc22.  While removing
the GLIB_DISABLE_DEPRECATION_WARNINGS defines does not lead to problems at least
with my current Fedora 18 environment (and, according to dtardon, "guessing by
the date, it was on f16 or f17" where that fix was relevant), having the defines
does cause -Werror=unused-macros at least in one RHEL 6 environment.

So I'm reverting for now, in the hope that should any warnings re-appear, they
can be addressed by applying the recent s/-I/$IFLAGS/ approach to GTK_CFLAGS in
configure.ac.

Change-Id: I5a3e4efabb88eb06304dd8b9eee6d8867fd77be5

...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