Before commit 653b53287c, editengine
objects had a pair IsVertical/SetVertical, which queried and set
a boolean flag (and SetVertical also had a second argument to set
another flag).
The mentioned commit had introduced an inconsistency, changing
SetVertical to only set a single flag, but at the same time making
IsVertical to return a synthesized result from two values: vertical
and rotation. Additionally, GetDirectVertical was introduced to
complement SetVertical.
In many places, the use of synthetic IsVertical looks suspicious,
especially where it is used in combinations with SetVertical. But
here I don't change existing logic, and only rename the methods,
so that in case someone sees an actual problem, it would be easier
to spot the method mismatch.
The end result is that now we have a proper getter/setter pair
GetVertical/SetVertical, and also IsEffectivelyVertical, named to
reflect that it calculates its return value.
Change-Id: I38e2b7c5bd7af0787dd7a1c48e1385138dac80b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119315
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
just pass a reference instead and spread that around to some similar
cases
Change-Id: Ifb2dee8c7bf02a9f01982b928c90666cbbdd84fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115759
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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>
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>
This is a prerequisite for making conversion from OUStringLiteral to OUString
more efficient at least for C++20 (by replacing its internals with a constexpr-
generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount,
conditionally for C++20 for now).
For a configure-wise bare-bones build on Linux, size reported by `du -bs
instdir` grew by 118792 bytes from 1155636636 to 1155755428.
In most places just a u"..." string literal prefix had to be added. In some
places
char const a[] = "...";
variables have been changed to char16_t, and a few places required even further
changes to code (which prompted the addition of include/o3tl/string_view.hxx
helper function o3tl::equalsIgnoreAsciiCase and the additional
OUString::createFromAscii overload).
For all uses of macros expanding to string literals, the relevant uses have been
rewritten as
u"" MACRO
instead of changing the macro definitions. It should be possible to change at
least some of those macro definitions (and drop the u"" from their call sites)
in follow-up commits.
Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
- document key combinations in README
- dump data into workdir as editenginedump.log
- move as static function into EditEngine class
- get rid of the EditDbg class and editdbg.hxx
Change-Id: I965f0143a9a275a289b202f54c0ea65da63c52f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97873
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
90% of cases pass GetSizePixel as the Size arg already
and this aligns Window::Draw with how Window::PaintToDevice
works
Change-Id: If5b024179a4b7a3b099177c2f6d4b1fb006b95ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94644
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Use it instead of classname::getImplementation from UNO3_GETIMPLEMENTATION_*
Change-Id: Ifcc8cfcd6369c576250008c76ce31ba79ea3a596
Reviewed-on: https://gerrit.libreoffice.org/74107
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Replace with UNO3_GETIMPLEMENTATION* macros.
Replace single usage of IMPL_XUNOTUNNEL_MINIMAL with it's body.
Change-Id: I7d4ad76399b999ebb2178ecf57edcf6bd2aa6c3e
Reviewed-on: https://gerrit.libreoffice.org/73424
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I6e97c7ed6c0211dfafee83b9bdbea672e415fc49
Reviewed-on: https://gerrit.libreoffice.org/69715
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I98f49765c6b74808dcbd692e0f375dd2848fcfd4
Reviewed-on: https://gerrit.libreoffice.org/65614
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ie87d27dd2c385a63349e0b322fd067ba03d2d152
Reviewed-on: https://gerrit.libreoffice.org/64479
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Iabe571aa8f00492902c499094bea8365a3e17fca
Reviewed-on: https://gerrit.libreoffice.org/63623
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: If18c80fc64e55d797953e24e40e5d5e62bd9c625
Reviewed-on: https://gerrit.libreoffice.org/63453
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Mike Kaganski