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>
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>
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun::star::resource::OfficeResourceLoader
com::sun::star::resource::XResourceBundleLoader
com::sun::star::resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
change various ResId classes that use conversion operator to OUString to
functions that return a OUString
drop various defines
drop unnecessary toString calls
Change-Id: Ibeccdf2b91a46a2ed5b4b74e6024e301a023bc92
Reviewed-on: https://gerrit.libreoffice.org/37817
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
* Add GPG implementation of css::xml::crypto UNO interfaces (part of that is only stub atm)
* List gpg keys along with other certificates
* Viewing gpg certificates: Not all properties are implemented yet
Change-Id: I7f60b26efe949a94bf8fe1b8d4d428002c2995b1
Reviewed-on: https://gerrit.libreoffice.org/33843
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Siegmund Gorr <siegmund.gorr@cib.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
...and remove some unncessary using directives/declarations, in preparation of
removing now-unnecessary #includes from cppumaker-generated files, post
e57ca02849 "Remove dynamic exception
specifications".
Change-Id: Iaf1f268871e2ee1d1c76cf90f03557527ebc9067
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
"Dynamic Exception Specifications" for details.
Most changes have been done automatically by the rewriting loplugin:dynexcspec
(after enabling the rewriting mode, to be committed shortly). The way it only
removes exception specs from declarations if it also sees a definition, it
identified some dead declarations-w/o-definitions (that have been removed
manually) and some cases where a definition appeared in multiple include files
(which have also been cleaned up manually). There's also been cases of macro
paramters (that were used to abstract over exception specs) that have become
unused now (and been removed).
Furthermore, some code needed to be cleaned up manually
(avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no
configurations available that would actually build that code. Missing @throws
documentation has not been applied in such manual clean-up.
Change-Id: I3408691256c9b0c12bc5332de976743626e13960
Reviewed-on: https://gerrit.libreoffice.org/33574
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The signature manager always creates an XML helper, and optionally creates a
PDF helper as well. Both of them initialize xmlsec, and when the signature
manager is deleted, there are two de-inits, leading to an assertion failure in
xmlsec.
Fix the problem by moving the duplicated xmlsec init to the signature manager.
This has the additional benefit that general security-related code no longer
has to talk to the XML helper, it can use the signature manager, which feels
more natural. (What viewing a certificate had to do with XML?)
Change-Id: If6a6bc433636445f3782849a367d4a7ac0be7688
Reviewed-on: https://gerrit.libreoffice.org/30695
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
xmlsecurity is such a mess. Too many different classes that actually
have more or less identical life-time, with names that smell of
delusions of grandeur. "Manager", "security framework controller" etc
for stuff that actually exist only during the execution of a simple
dialog. And then a "helper" class that actually in on a higher level
than a "framework controller". But oh well.
Change-Id: I86e461b1bc91a0d8f5b7fb9f13a5be201729df1e
This just allows the menu entry in Draw to reach
SfxMedium::SignContents_Impl(), and then call signDocumentContent(),
which shows the dialog (where the signature itself isn't visible yet).
Do this by not assuming a ZIP-based storage at various places when we're
not working with an "own" format.
Change-Id: I030d0f636d1aab98369024f3f10a975ea2786d59
Reviewed-on: https://gerrit.libreoffice.org/29774
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This splits most of the PDF signature code out of the pdfverify
executable, and puts it into the xmlsecurity library instead.
The PDFSignatureHelper now attempts to verify PDF signatures, and code
in sdext / sfx2 also calls it (even if PDF is not a ZIP-based format).
Change-Id: I7b8b3ac9c976e4ea4f3796b1cda07c8a2c97bd02
Reviewed-on: https://gerrit.libreoffice.org/29751
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
The free-form string attached to a signature is called description
during ODF/OOXML signing. The certificate chooser dialog has an input
field to provide that. The PDF export dialog's signature tab reuses
this dialog, but also provides an an own reason input field for the same
purpose.
So in case the generic dialog's description field is filled, don't
simply throw away that string, but set the pdf export's reason field to
the same value.
XDocumentDigitalSignatures.idl is not a published interface and it is
used only internally, so the API change is only nominal.
Change-Id: I6d4cf0b3f586417a76a052dc30c960478a95c984
The issue of 362d4f0cd4 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
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>
Noel Grandin