as part of a longer-term goal of doing our
widget rendering only inside a top-level render-
context.
I moved all of the OutputDevice-related code that existed in vcl::Window
into a new subclass of OutputDevice called WindowOutputDevice.
Notes for further work
(*) not sure why we are getting an 1x1 surface in
SvpSalGraphics::releaseCairoContext, but to fix it I clamp
the size there
(*) might have to dump VCLXDevice, and move it's code down into VCLXWindow and VCLXVirtualDevice
(*) can we remove use of VCLXDevice in other places, in favour of just talking to the VCL code?
Change-Id: I105946377f5322677d6f7d0c1c23847178a720b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113204
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
because it introduces a link-time dependency of vcl on toolkit,
and toolkit already depends on vcl
This reverts commit f7a86c5cdf4323c99d26512bf78de7f7c380667d.
Change-Id: Ibdd4f3e8221d70e2abd8fcbda67f85af3ac0396e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115547
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
I was wrong, the Concat framework already optimised appending
numbers by stack-allocating small buffers, so include
them in the plugin
Change-Id: I922edbdde273c89abfe21d51c5d25dc01c97db25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115037
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
which can use the more efficient *StringConcat
Also fix a crash in stringview plugin which
started happening while I working on this.
Change-Id: I91a5b9b7707d1594d27d80b73930f5afac8ae608
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114568
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
create vcl/locktoplevels.hxx for the utility to set all
toplevel windows modally locked
Change-Id: I964484d238852e830e1e5c0b86b3bebb3b41a6b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113889
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(*) fix bug in SfxToolBoxControl::StateChanged where it was using the slot id
instead of the toolbox item id
(*) I left the logic in SbaTableQueryBrowser alone, but it looks suspicious,
casting slot ids to toolbox ids
Change-Id: Ied229164c27fb4456b0515c6fdcbd1682766a1a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112186
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
... a leftover from times when there were methods for 16-bit
as well as for 32-bit indices. 16-bit indices were removed in
commit 62f3f3d92aa204eaaa063b30d7ade44df501b997.
Change-Id: Idf8b1160e68e8b303cf75ea79dd7dbb3bd00275d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112187
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
using operator= implies that overwriting an SdrObject is a
useful operation, but that is not at all true - they are typically
linked into and referred to by many other things.
So rather use a copy-constructor.
Also clean up a couple of weird "do some stuff after the clone"
code into the main copy constructor.
Change-Id: Iefc1481b527602748b5f3abed06e7cca66c0581c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110633
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Revert "property browser appearing as a blank area when changing modules"
This reverts commit a07f0a57378a8901d647e3e5de8347445a82ea17.
I no longer see a stray property browser area with this reverted anyway.
Change-Id: Icbf7c59f582172a9baef9e512c7ddbf7fba0ff85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109752
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for
details.
(Turned some affected variables in included files into inline variables, to
avoid GCC warnings about unused variables.)
Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
to make it more obvious when we are constructing heap OUStrings
code and potentially inadvertently throwing away performance.
And fix a handful of places so revealed.
Change-Id: I0cf390f78026f8a670aaab53424cd31510633051
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107923
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
left behind after....
commit 867af25bd8d36c7e5ef6f16c2876ac82e63648cc
Date: Fri Jan 22 12:04:05 2016 +0100
tdf#96683 Move tabs in Basic IDE to an own row
before that it could be used to assign sizes to the tabbar vs
scrollbar when they were on the same line. Now that they are on
different lines it shouldn't be there.
See tdf#87684 for the similar calc case where
Office::Calc::Layout::Other::TabbarInlineWithScrollbar exists to
re-enable this feature for calc.
Change-Id: I6430e13ab79f4c424ae35f7b8e3ad7bd47ec201b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106275
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
...to "Find functions that take rtl::O[U]String parameters that can be
generalized to take std::[u16]string_view instead." (Which in turn can avoid
costly O[U]String constructions, see e.g. loplugin:stringview and subView.)
Some of those functions' call sites, passing plain char string literals, needed
to be adapted when converting them.
Change-Id: I644ab546d7a0ce9e470ab9b3196e3e60d1e812bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105622
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
