This is preparing to change how GraphicManager works where it
won't base itself around GraphicObject anymore but Graphic. No
functional or cosmetic change was made to the classes, only
changes that were needed because of the move and rename.
The only thing that wasn't moved is the GraphicRenderer as it
is not needed in vcl for now (but makes sense to move it in the
future to keep graphic stuff together).
grfmgr was renamed to GraphicObject as the GraphicManager will be
changed a lot and most likely moved out, so the name grfmgr won't
make any sense anymore.
All the UNO implementations were renamed with a prefix Uno and
used the same name as the class name. This is made to be more
specific which are the Uno objects (for example graphic.cxx
contained the implementation of XGraphic, which is similar to
graph.cxx contains Graphic).
Change-Id: I54a2fa6c7e997469aaa7770db05244adb9f64137
Reviewed-on: https://gerrit.libreoffice.org/51068
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
When changing to use "GraphicBitmap" property instead of
"ImageURL", the import wasn't adapted and there was no test which
would warn of such an situation. This also changes the difference
between writer and impress where impress used "Graphic" and not
"GraphicBitmap" property.
Also adds missing tests for both writer and impress
Change-Id: Ieed629d2d37f7806d63e729b6ef23cd848593071
Reviewed-on: https://gerrit.libreoffice.org/50140
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
because I
(a) forgot to insert parentheses which changes the meaning of some expressions and
(b) I now use the AdjustFoo calls when changing unary operations, which reads much better
This reverts commit 2096aac8b9.
Change-Id: I4b5941c4119b95aaefb9180a0ca95a1dbb4ec317
Reviewed-on: https://gerrit.libreoffice.org/49844
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
instead of overloading the nMemberId field
and thus fix various places that were effectively setting the METRIC
flag and causing a warning in SvxUnoConvertToMM
And fix bug in
sw/source/core/unocore/unomap.cxx
where the PropertyAttribute::READONLY was in the wrong place,
ever since
commit 84a3db80b4
Date: Mon Sep 18 23:08:29 2000 +0000
initial import
Change-Id: Ifc2bf56709f19aea75300b2fda62ce551efc26af
Reviewed-on: https://gerrit.libreoffice.org/48950
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
...similar to bf7ea94632d33eb3ed3eae26bca36906eda15257
"SvxAccessibleTextIndex::mnEEIndex need not be bounded sal_uInt16"
Change-Id: I88d107ae1eb16c8fc3322f1c6318df62c079cf23
Reviewed-on: https://gerrit.libreoffice.org/48775
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It was originally introduced with type USHORT
(a909acb700 "#98735# Refactored
unoedit/unoedacc.cxx"), then shortly after changed to sal_Int32
(a0089a21f0 "#98735# Fixed various off-by-one
mistakes"), presumably because it needed to hold values slightly larger than
USHRT_MAX.
But at least since the surrounding code has been changed to use sal_Int32
throughout (e.g., structs like EPosition and ESeleciton in
include/editeng/editdata.hxx with 3cbfcee36d
"xub_StrLen and tools/string.hxx final straw"), there appears to be no more
reason to effectively restrict mnEEIndex to sal_uInt16 values.
Change-Id: I78f02be1f2736a626a836ac992230a74cc669fd3
Reviewed-on: https://gerrit.libreoffice.org/48766
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...whose ctor already zero-initializes all members, so the first two memsets are
unnecessary. And spell the third memset as explicit assignments.
Change-Id: Ie5079711b152bac7f0a8d52d7889879157a35b5d
Reviewed-on: https://gerrit.libreoffice.org/48390
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: I09a4d688e6f3c1ecbe05a7d27ebd955e8ba1eb65
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
use a strong-typedef template to give which IDs a type, which we can
carry around to do a
(a) little bit more convenience when Get()'ing them
and
(b) a little bit of enforcement of which PoolItem subclass each ID uses
Fix a bug in casting EE_PARA_BULLETSTATE to the wrong subclass
in AccessibleEditableTextPara::_correctValues
Change-Id: I015ce8b3b0f6d21308af182afa3caf122c877a5b
Reviewed-on: https://gerrit.libreoffice.org/44587
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Impress has a limited support for fields - this includes support
for DocInfo.Custom field, which shows the user defined custom
fields that are used in TSCP. This commit adds minimal support
(only what is needed for TSCP) for DocInfo.Custom field but only
supports string fields for now. It is not possible to add the field
manually, at least not until the full support is added.
Change-Id: Ib3b73ab22fd4fe65ab6fb5173fe035a3359deea5
Reviewed-on: https://gerrit.libreoffice.org/44041
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Insert constructor everywhere, except a couple places that apparently
want to compare GetMapUnit().
Change-Id: I1910deb60562e5e949203435e827057f70a3f988
Caolán McNamara