| Age | Commit message (Collapse) | Author |
|---|
|
now that find-unused-includes was expanded with detecting these
Change-Id: I9f21ad1a85c1e3178cad98464b2ba407d909b62d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167638
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Tested-by: Jenkins
|
|
Currently SvtOptionsDrawinglayer::IsAntiAliasing() is used
in the constructor of the VCL based processor2Ds to decide
if AA is to be used or not. Using this inside the
constructors makes it currently impossible to use a
primitive renderer independent from these settings,
except when changing these settings temporarily what
may influence other renderings and is a hack.
The setting SvtOptionsDrawinglayer::IsAntiAliasing() is
intended to decide if LO shall use AA mode from user's
perspective, this means for the EditViews of the Apps
and some other occasions (previews, exports, conversions
to bitmap, ...).
This works currently since all visualizations for these
purposes use newly constructed primitive renderers. But
there is no way to use primitive renderers independent
from that setting. For future renderers which might be
used for other purposes this is not sufficient, there
has to be a method to create a renderer using e.g. AA
independent of the global setting.
To allow that, move the deciding flag to the already
used geometry::ViewInformation2D. To not change anything
initially, use the global flag for now to init that
default value at ViewInformation2D.
I took the opportunity to adapt ViewInformation2D to
no longer being read-only and not changeable, it uses
internally an impl class based on cow_wrapper already
anyways. Extending this would lead to the constructors
getting even bigger, when usually only 1-3 values
need to be changed and many usages want to copy an
existing instance and modify it. Adapted that usages
to a much smaller footprint.
Up to this point this does not change anything, but
move the usage of the SvtOptionsDrawinglayer to the
defaults (constructors) of the involved class
ViewInformation2D. Using this then in the primitive
rederers should be safe and will allow to use a
primitive renderer with or without AntiAliasing
independent of the user setting, so also for non-
EditView usages.
Also already added the PixelSnapHairline setting, this
will also be needed independent of user settings to
have full freedom of usage.
Unfortunately I cannot use SvtOptionsDrawinglayer
methods
::IsAntiAliasing() or
::IsSnapHorVerLinesToDiscrete
inside ViewInformation2D where I would need it. It's
now in drawinglayercore and thus not linked against
svtools (svt) anymore.
Thus I have to do some forwarding mechanisms to get
the correct values available in ViewInformation2D.
Not nice, caused by creating drawinglayercore...
Change-Id: I9f572ce67e5d86a242188bdc6d4ba7c9a12f6a9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142393
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
follow up to commit 1103727fb24b368419ea0cfd2382560ef6b82f43
Change-Id: I227042f4703f3f4c18a8dc0355f044d2ad7dfb2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126838
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I95918275653714577e2d6728dd3947c7fbb66d8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121360
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
We actually never use extended information when normally using
the ViewInformation2D. The exception here is when we construct it
from property values, where the unknown property values are then
stored into the extended information sequence and then later
reconstructed when we convert it back to a sequence of property
values. Just for that case we don't neeed to expose the extended
information to the outside and create it, as that is then a
implementation detail for the UNO use case.
I am also not convinced we need it when creating ViewInformation2D
with the sequence of property values - it certantly not expected
that we need to preserve the property values at all, but that is
something that needs to be checked.
Change-Id: I3b8d533cd412aac8b89ca2921738d6487be5cf45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119720
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This patch splits the polypolygonprimitive2d.hxx into:
- PolyPolygonColorPrimitive2D.hxx
- PolyPolygonGradientPrimitive2D.hxx
- PolyPolygonGraphicPrimitive2D.hxx
- PolyPolygonHairlinePrimitive2D.hxx
- PolyPolygonHatchPrimitive2D.hxx
- PolyPolygonMarkerPrimitive2D.hxx
- PolyPolygonSelectionPrimitive2D.hxx
- PolyPolygonStrokePrimitive2D.hxx
... and fixes the include files and pre-compiled headers
Change-Id: I23982e0c81e8992f69e14cbac8e86858266b9999
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91603
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: If2644743ab0d9b78d42d1d2fe6fa22c83472d2c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87065
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
instead of returning a Primitive2DContainer from each method which we
are then going to immediately append to another container, pass down a
single container by reference which we can append to
Change-Id: I0f28a499d2ec54f7111a7044c30099767aa079e1
Reviewed-on: https://gerrit.libreoffice.org/30258
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
A ridiculously fast way of doing this is:
for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \
--exclude-dir=workdir --exclude-dir=instdir '^
{3,}' .)
do
perl -0777 -i -pe 's/^
{3,}/
/gm' $i
done
Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c
Reviewed-on: https://gerrit.libreoffice.org/22224
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
|