Especially the ones from our developer machines as they are better tested than anything else.

Change-Id: Id6ff6bcae314c03453d82ee4e64aaef1bd5ed84a

Normally you only get the Microsoft OpenGL 1.1 driver for RDP so it is save to just block it.

Change-Id: Id9b3af23d56926b09316fbf8b873e271060d2c6a

Removed XDashStyle

Change-Id: Id14802a007a90508ee033e1dc964c57d3d5ef582
Reviewed-on: https://gerrit.libreoffice.org/13213Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: Iae06202acc825ab95389465b9aea846f2772df26

Effect import is so poor by now that this changes does not seem
to have any effect, but later it can be helpful.

See also:
81cd386f
and
664a56b3

Change-Id: I4e6a9952aa138959ab273db0494ef0cf76d8fc24

See also:
81cd386f

Change-Id: Ibb21d3e5b52a4d4996202acd4a989910fa223632

The problem was that the background color defined by theme
was not imported correctly, because the different fill
style comes from different sources (master slide, theme,
direct formatting) were applied on the shape in wrong order.

To solve this we need to store master slide defined fill style
in a different variable so theme style can be applied after master
slide defined style but before direct formatting.

Change-Id: I99ea981858b9fa391915570187c8ddfdf2be1f7a

For some reason PopupWindowControllerImpl::WindowEventListener is getting
the VCLEVENT_WINDOW_HIDE event twice, and while processing the second one
the ToolBox no longer has an active down item, which results in a
IndexOutOfBoundsException in VCLXAccessibleToolBox::getAccessibleChild,
because ToolBox::GetItemPos(0) correctly returns TOOLBOX_ITEM_NOTFOUND.
But when a ToolBox has at least one separator, ToolBox::GetItemPos(0)
"detects" its position as the current down item, and no exception is
thrown.

Probably it just hides the bug, because it seems to me that getting
the hide event twice is the real bug here.

Change-Id: If018350dd91cd959c0c8f7d6859474f95fb8cd1e
Reviewed-on: https://gerrit.libreoffice.org/13173Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
Tested-by: Maxim Monastirsky <momonasmon@gmail.com>

It was always used with T=css::uno::Reference<css::text::XTextRange>

Change-Id: If79413cf68ad5d5f6fc7aba1c065f49e5781d71d

Change-Id: Ie036cafd769328d9d5cc42265534ed8f7c0d0f2c

Change-Id: If0dd607823cad5dbc2da2df93ed0847a34791b58

Change-Id: I3354f82a3dd0a598b5405ab32c5d1b0d370829c3

Change-Id: Ic49033c85f77be8ba415078ae5e3518ef0faae75

There were two problems here. First, commit
bbe3627e (rtftok: stop sending
sprm:CRgFtc{0,1,2} tokens, 2014-03-05) broke the use-case when the font
encoding is 0, but it's present. Before that commit, we parsed the font
encoding instantly; after that commit we parse it once we have a font
name. If we do that, then we have to have an idea if we have a font
encoding. Given that 0 is a valid encoding, use -1 for the "have no
encoding" case instead.

Second, commit 7839633f (fdo#85889
handle pc, pca and mac rtf keywords in writerfilter, 2014-11-24) abused
m_nCurrentEncoding, which is meant to be used within the font table
only. The problem with this is that this way only the first font will
get the encoding, while the spec says it should be used in every context
where there is no other explicit encoding. Fix this by setting the
default encoding for those 3 control words instead -- and consider the
default encoding in getEncoding().

Change-Id: Ia1d71f8ce70f2a53a3770b4840e21362d082e71f

Presumably, the names should be unique, so it's the same.

Change-Id: I74907b97bc25f9512d4f7514162360e8b21ad4a5

Change-Id: I83fd835a8a198ff469cfaa0441c938acf9433862
Reviewed-on: https://gerrit.libreoffice.org/13206Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>

Change-Id: I8d61702af9d650149fd1fced253007fad4605246
Reviewed-on: https://gerrit.libreoffice.org/13200Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>

Conflicts:
	vcl/inc/headless/svpgdi.hxx

Change-Id: I4cd9163bcbb8cdee21e5bce3303894923c4238d6

Change-Id: I90a44d9e826558a80174a452626c8e8438e25666
Reviewed-on: https://gerrit.libreoffice.org/13198Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>

Change-Id: I6601d40f86d7abdaffef0cb0167e84efa54548ba
Reviewed-on: https://gerrit.libreoffice.org/13192Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>

Change-Id: Iee75eee636e333526b1fb35e8071ed5e9a194bb2
Reviewed-on: https://gerrit.libreoffice.org/13193Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>

Change-Id: I66a762ac267f48b9866d6ccb0fec9542eec52aaa
Reviewed-on: https://gerrit.libreoffice.org/13188Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>

Change-Id: Ia6b1c7f9d7ad3cdf9dd5aa06d1c0ba86a71607ab
Reviewed-on: https://gerrit.libreoffice.org/13187Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>

Change-Id: I04514498e9f6466416d08eb0e1736dcebe931e71
Reviewed-on: https://gerrit.libreoffice.org/13186Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>

Change-Id: I943351a9050f78ea3495807570c51e0c7782ead3

Change-Id: Ic090e1b9d13780e7e895a85901d3329cc5703688

This should fix a huge number of our xls export crashes. I just picked
my test document for the commit message. I suppose that nearly all
reported XLS export crashes are the same issue.

At the same time this should improve the performance of our XLS and XLSX
export a bit.

Change-Id: Id19e2515e75e10527d3af62d671377bec23f99e8

This helps with some huge documents and takes 90% of the time of the
import. The correct next step is to get rid of UNO in the calc style
import.

Change-Id: I6cbd315906405d8f438d99effad122af8edeb01d

Change-Id: Ia732e283fa07ec5ece58e49dca2dcc5c61495109

Change-Id: Ia17a5d983afb98e0b348909a66be85ea55f8a47a

Change-Id: Ib3b8b70aa50dd1a42108e3e9091350bf1d315b03

Change-Id: Ifa6ba5735582effc27ac68556c2367077705d1d6

Change-Id: I524883b0f0bbce9a8b6f893771f144feeee49934

Do it the same way as position'n'size dialog does, for that matter
move shared code into a separate header/class.

This fixes regression from .ui migration that omitted spinbox limits

Change-Id: I884904719b2608dd80aecc5d7ffb3923de71774d
Reviewed-on: https://gerrit.libreoffice.org/13174Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Katarina Behrens <bubli@bubli.org>

Change-Id: Id210dad9b44f0164bfb247266a99c5886bfb7cbd

DummyApplication is, frankly, a hack. Application is an abstract class because
Application::Main() is a pure virtual function. However, as DummyApplication
shows - this is not necessary because InitVCL() just makes a dummy app anyway.
Anyone who uses Application::Main() will get a warning.

Also: I want to move some of the global data into Application, and I can't do this
whilst it is an abstract class. Given it's not necessary, then I'm getting rid of
Main() as a pure virtual function.

Change-Id: I425cf6feae4866f5670963ee9905f6161e421dd2

Change-Id: I70a2a9fc8f30e915f371e691c58b0d58b1e3ad86

Some address fields of ScExtTabSettings are initialized invalid and
maybe kept invalid, on purpose, so take care of that and use only the
valid fields.

Change-Id: I37cbf8ff49c6ccf38bfac3e1c8c6492ac7bad61b

Change-Id: I37c2126d8b9170334042c7bf380d04c5885c4cb1

Change-Id: Iec51b032c96189b20cd43934c477b587da3011a7