This is used in parsing of meta Contexts across different
modules. This also involved moving to XFastParser for
parsing xml filters in sw, sd, starmath.
Change-Id: Ic663aaac6cb20ee8ce5b97cae87c93220f5a2929
Reviewed-on: https://gerrit.libreoffice.org/42989
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>
just the straight-forward MessageDialog cases first
a) remove border_width from message dialog .ui so as to take
the default border width
b) retain 12 as default message dialog border for vcl widget case
c) remove layour_style from message dialog button boxes so as to
take the default mode (a no-op for vcl widget case)
d) use gtk response ids (vcl builder will converts to vcl ones)
Change-Id: I7de281093a1b64f92f71ca11e7cbba42bb658154
Reviewed-on: https://gerrit.libreoffice.org/50143
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
it has exactly the same effect as just letting the constant be converted
to Color via the Color(ColorData) constructor.
This commit is part of the process of removing ColorData.
Change-Id: Ie12ad451ba3f43a627ebdbb132a5369f5760ba52
Reviewed-on: https://gerrit.libreoffice.org/50038
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
the plugin 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 457220bc2c.
Change-Id: I2c6b1092c8bfa4fa14acbc7445f546d43cb2a86e
Reviewed-on: https://gerrit.libreoffice.org/49833
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
A side effect of the .ui migration is that we use a lot less HIDs
in the code. A lot of files still contain helpids.h includes
even if no actual HID is referenced.
This cleans up directories r* - svx*.
Found with:
git grep helpids.h | cut -d : -f 1 | xargs grep -c HID_ | grep :0$
Change-Id: I81bdb80161b0207f5df651eb17c58caef44250d3
Reviewed-on: https://gerrit.libreoffice.org/46869
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@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: I690ddd7eeb5fbac979292a382074e9b29c065416
This way, it is possible to have all the strings translated in dialogs even
when different users use different languages. [It was already possible
to have different languages previously, but not everything in the dialog has
switched - like the buttons at the bottom of the dialogs etc.]
Change-Id: I29a5ae6d31a370eec60397884200b684ec1bf5b9
Reviewed-on: https://gerrit.libreoffice.org/46417
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/46979
Tested-by: Jenkins <ci@libreoffice.org>
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>
Fix the non-obvious and potentially dangerous recursion that is
implicit in xmloff's context code.
SvXMLImportContext::CreateChildContext() now always creates a
SvXMLImportContext, does not delegate to SvXMLImport.
Rename CreateContext to CreateDocumentContext, to make its purpose of
creating only the top-level context more obvious.
With the previous changes to CreateContext overrides in sw,
reportdesign and dbaccess, this hopefully shouldn't break anything.
Change-Id: I9e147bf6297bbac9e8470454881da73f6e39db0a
This was handling XML elements at 3 different levels; add some more
context classes to handle the nesting better.
There was one tricky case: the ORptExport::exportContainer()
can export a office:report element inside office:body
inside report:sub-document, but i don't know how to
create a report like that.
This was previously handled on import via the fallback to
SvXMLImportContext (created for office:body) calling
ORptFilter::CreateContext(), but now it needs explicit handling
in OXMLSubDocument::CreateChildContext_().
Change-Id: I839986599b2b936f57bb65da355ac1be811fe999
...which had been left out because "lots of our code uses this style, which I'm
loathe to bulk-fix as yet", but now in
<https://gerrit.libreoffice.org/#/c/45060/1/> "use std::unique_ptr" would have
caused an otherwise innocent-looking code change to trigger a
loplugin:unnecessaryparen warning for
pFormat = (pGrfObj)
? ...
(barring a change to ignoreAllImplicit in
compilerplugins/clang/unnecessaryparen.cxx similar to that in
<https://gerrit.libreoffice.org/#/c/45083/2> "Make not warning about !! in
loplugin:simplifybool consistent", which should also have caused the warning to
disappear for the modified code, IIUC).
Change-Id: I8bff0cc11bbb839ef06d07b8d9237f150804fec2
Reviewed-on: https://gerrit.libreoffice.org/45088
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Caolán McNamara