Linux SAL_USE_VCLPLUGIN=svp and the clipboard

[Jan-Marek Glogowski]

Am 03.04.20 um 17:09 schrieb Stephan Bergmann:
> It is not clear to me what the intended behavior of
> SalInstance::CreateClipboard is, and thus how the two tests (and the
> expected tiledrendering behavior that
> ScTiledRenderingTest::testMultiViewCopyPaste apparently tests?) should
> be fixed.

I was thinking about this, when we were talking about clipboard on IRC a
few days ago.

LO has three use cases for a clipboard:

1. "normal" LO usage, where the clipboard maps to the system clipboard
and is a system-wide shared resource (all backends, except svp). Works
as expected.

2. headless LO test usage, where it probably would make sense to have
one abstract clipboard per LO instance.

3. LO online, where you want a clipboard per user in the best case, or a
never shared clipboard, so different users don't share a clipboard.

I did expect back then, that SalInstance::CreateClipboard would also be
a shared instance for LO, with some special handling for LOOL, but I
never checked that.

I guess LOOL works, because of 3. and that every view holds it's own
XTransferable clipboard content on copy. And it "registers" its own
css/datatransfer/clipboard/XClipboardOwner.idl when it sets the
clipboard by setting the context.

So the view sets the clipboard and is informed, if it loses the
clipboard. With the non-shared instances, you never lose the clipboard,
so you don't need to check it for changed content on paste, as you're
the sole possible owner and paste in LOOL works fine.

Or there must be some comphelper::LibreOfficeKit::isActive() handling
somewhere in all modules, as Miklos suggested.

And as you realized, UItest running without the SVP backend can't
reliably use clipboard functions, as these tests don't run with
--headless. Guess some new environment var or --no-system-clipboard is
needed, if we want to test VCL backends with UI tests together with C'n'P.

Jan-Marek