I (tried to) keep these files consistent locally with astyle in the past,
switching to clang-format makes sure that the recent problem with introducing
inconsistencies in these files doesn't happen again.
(On the flip side, it's great to see that now others also touch this
PDF/pdfium code. :-) )
Change-Id: I6065eab77c584197a82fe48e7d3e81b445106efd
Reviewed-on: https://gerrit.libreoffice.org/51701
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
and use the underlying comphelper methods rather. This is so that I can
break the dependency that tools has on sax, and can add methods that
make sax depend on tools.
Change-Id: I8a2d6ce2ffc3529a0020710ade6a1748ee5af7d5
Reviewed-on: https://gerrit.libreoffice.org/50767
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
Automatic rewrite (of loplugin:cstylecast and loplugin:unnecessaryparen) after
cab0427cad "Enable loplugin:cstylecast for some
more cases" and a409d32e7f "More
loplugin:cstylecast"
Change-Id: Ib3355159dd08333e1b7a8d091caf2069cdcc7862
Reviewed-on: https://gerrit.libreoffice.org/48317
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: Ica6e96072435aa4df4e74accdfe06f798a640bbe
I (tried to) keep these files consistent locally with astyle in the past,
switching to clang-format makes sure that the recent problem with introducing
inconsistencies with automatic loplugin rewrites doesn't happen again.
Change-Id: If49c96b6e9e6ed50beb69c70e37125dff5607f76
Reviewed-on: https://gerrit.libreoffice.org/47332
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
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>
For signing, preselect the key in the list of available keys.
For encryption, when 'encrypt to self' bit is set, add user's key
to the list of keys to encryption.
Change-Id: I5bbfd0e2cc97b76c1304a2a345a51cf83bc5949e
Reviewed-on: https://gerrit.libreoffice.org/46694
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
This is mostly just the offapi/ part, more C++ code can be removed in
xmlsecurity/ after this.
It seems to be unlikely that this non-published service was used by 3rd-party
code, since it was specific to other xmlsecurity/ code, not generic
functionality that could be useful in other contexts.
Change-Id: I0d798577a42445e65a4c5178fcb4464ea03bc56e
Reviewed-on: https://gerrit.libreoffice.org/46442
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
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>
Noel Grandin