Change-Id: I1947dc84c91e2e01072fbff3e97aa94d514ecb5a

Do away with an early hack to create the floating window with every
invalidate.

This gets rid of persistent blinking when moving the mouse over a
listbox, for example.

Change-Id: Ida9367156605edc9835529f83529363ad97beaee

Change-Id: I193e0ab82e998905b670f7de73daae784de3ef00

Change-Id: I4ccef76cc3b2926dd8916f825671bb732e101027

We can specify whether it is an invalidation or something else in the
payload.

Change-Id: I95c5fc0a0a88b5277eaa93c8d1f9b937bddce7b3

Change-Id: I06a081835d246f752e57f8cc289162ed31fc91d4

With this, key events successfully work now.

Change-Id: I6dc6aff91dea08fcbc7ab840a77e2542ab9048ce

gtk_window_move them to the position broadcasted to us by vcl

Change-Id: Id27b52a24e721b51d7a153cc7c0e03197a99ee2f

Now gtktiledviewer can show floating window dialog widgets when user
clicks any of such widget in the dialog.

Change-Id: I13d756f236379bc8b2041ed41cb7b502f7fd9b24

Change-Id: I344f5a9c7167abfde15dcd21c747819cc79b12b1

Change-Id: If84aaac87beebf69d92db5446fc713d8cc20421e

Change-Id: Icfc210b08c7f1d8ebaf9c731ed64bb128cfc4356

Change-Id: I1d744c91f01eb098e9273d2459b63a5444558f39

For now, temporarily trigger paints for all the opened
dialogs whenever a dialog invalidation callback is emitted. This solves
the problem for some of the dialogs where hard coded uno command, which
we are using as dialog IDs in GTV, doesn't match with the dialog id
contained in the payload of the invalidation callback.

With this SearchDialog, AcceptChangeTracking and few others are
responding well to mouse clicks and invalidate instantaneously while to
invalidate and repaint some other dialogs, one needs to refocus them.

Change-Id: Iac2acbda60c8e2d0eabe65440f3fbda3ef271d7a

The current implementation works well - the mouse events are properly
handled by the opened dialog changing the dialog states.

However, since the uno commands (dialog IDs) are different from what is
returned by LOK_CALLBACK_DIALOG_INVALIDATE, the invalidation doesn't
instantaneously, so one have to make the dialog window out-of-focus and
then again back to focus to trigger the paint and see the updated dialog
state.

The mouse coordinates are forwarded in pixels as of now.

Enable mouse GDK Motion mask too for mouse move operation.

Change-Id: Ia915f734e8cbf4586da2b70da5840fe1568b39bd

Events from the dialog in GTV are forwarded correctly, but the events
are still not processed by the dialog in core.

Change-Id: Ib95ac0a3cd23f6cc2763c21425a67402b15f2de2

Change-Id: I94578b9e9c7fc2e6a9d14effe456d821768a0bcb

Change-Id: I914564f67716f4e218d42ac4f0545e46e9609389

Change-Id: I081508674a71c3beb89175e4f8ac3256e6bc6c6a

Change-Id: I7cb320a740cdb21da5a654cf99c887f5c7a8979d

These are used to supress any dialog invalidations emitted while
painting the dialog. We are not interested in any such invalidations.

Change-Id: I2a7b018124af501bce18adbff0f5db85adf5fce2

For now, just invalidate the whole dialog whenever any of the controls
in the dialog get invalidated.

Since during dialog painting, many such invalidations are triggered,
don't listen to them when we are painting.

Change-Id: Ia8fc12cf9469691d60e91ef770d687e5ff01a7ef

Hardcode modeless dialogs available in writer (very few) as of now in
the combobox.

Change-Id: I82d1442fbc71776dd64640ad048a0375ca041a67

After painting the dialog, also write width and height of the rendered
dialog. The dialog is rendered
always on the top left of the given canvas, so client can crop the
canvas accordingly.

Change-Id: If052058a6db8a85d4e28ec88cffcca05564b17f0

Change-Id: I6bc624272138f0e23d2e3abfd82b857fed12e12c

Change-Id: I7bd7f9cb33cd79d1e55ce51fe39917c5741bdf18

Change-Id: I1d85729a1ac1a99d33ea2bde1b50ccf4c05ca9a9

Change-Id: Ib05ecf5f92e0ae4adf99c4dd10d60e730a95cf45

Change-Id: I3468776797426b04c1cb3206dbb194837a652e16

Change-Id: I2ecf3050aa68a0f2986c43b651d71b662a77e55a

Since https://cgit.freedesktop.org/libreoffice/core/commit/?id=a95def1aed681bbb664ff24470e0da7c5a5530ac

Change-Id: I9104ab6c68b55f1405297182cba087d668947b0f
Reviewed-on: https://gerrit.libreoffice.org/43011Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

Change-Id: I3828113bce3b7d32e90e461a299986e363115a83
Reviewed-on: https://gerrit.libreoffice.org/43002Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Henry Castro <hcastro@collabora.com>

Change-Id: I20fd2665f9fed59b45127dd4aa3dbce0fc58ac17
Reviewed-on: https://gerrit.libreoffice.org/43006Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>

When we get an EMF+ comment record (which is NOT an EMF comment
record, EMF has comment records which is how you store EMF+
records, EMF+ records also have comment records for "private
data") then if we are a debug build then dump the private data
to stdout.

To make this work, set:

SAL_LOG=+INFO.cppcanvas.emf+WARN.cppcanvas.emf

Change-Id: I293875f45b692971379a5945ff7feb273bc54c73
Reviewed-on: https://gerrit.libreoffice.org/42558Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>

We should warn if EMF+ record < 12 bytes. Similarly, if the
record size is less than 12 bytes, that's evidence of a
corrupted EMF+ record, same with if the length or datasize
is too long. Thus we should warn at this point.

Also - if an if statement is not part of another if/else block
then best to have a newline separating them so they don't
look like they are part of that block.

Change-Id: I914c754fe7437d6d4b6f2e4aec2d28475eaf5d70
Reviewed-on: https://gerrit.libreoffice.org/43004Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>

Change-Id: I7fa638f8abe3b565f48d4ed69bd0fccf7c7872ac
Reviewed-on: https://gerrit.libreoffice.org/42689Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>

Change-Id: Idfb4c0e26a109157f95f3dfe2cfcdccbb2428502
Reviewed-on: https://gerrit.libreoffice.org/42995Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

Change-Id: I5b57d4f4a1e0c68fdc56d84392f4b1472a67e82b
Reviewed-on: https://gerrit.libreoffice.org/42992Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

if we're going to throw the base class of the exception hierarchy,
we can at least put a useful message in there to make the source a little
bit easier to locate.

Change-Id: I2f3106c99ba25125eacef8fa77e2f3a2c89f2566
Reviewed-on: https://gerrit.libreoffice.org/42968Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

Change-Id: I9952c560547b0668d8216edba1486638fa41e553
Reviewed-on: https://gerrit.libreoffice.org/42990Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>