LD_LIBRARY_PATH=/data/sbergman/lo-clang/core/instdir/program \
/data/sbergman/lo-clang/core/workdir/LinkTarget/Executable/unoidl-read --published \
/data/sbergman/lo-7.0/core/instdir/program/types.rdb \
>/data/sbergman/lo-clang/core/udkapi/type_reference/udkapi.idl
* no changes
LD_LIBRARY_PATH=/data/sbergman/lo-clang/core/instdir/program \
/data/sbergman/lo-clang/core/workdir/LinkTarget/Executable/unoidl-read --published \
/data/sbergman/lo-7.0/core/instdir/program/types.rdb \
/data/sbergman/lo-7.0/core/instdir/program/types/offapi.rdb \
>/data/sbergman/lo-clang/core/offapi/type_reference/offapi.idl
* (XDcoumentHandler getting moved around now is a consequence of this being the
first fully-automated generation of the file again after the manual
modifications done by the preceding 214e6caf2c
"[API CHANGE] remove BasicImport UNO interfaces" and
ebb66ee09b "Fixed update of the reference rdbs
to libreoffice-6.4.0.3-buildfix1".)
Change-Id: I841b6b5a059c78750fa7f02f9276c6b6f86c9afd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100892
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
19746d24aa "Update the reference rdbs to
libreoffice-6.4.0.3-buildfix1" had erroneously labeled
LD_LIBRARY_PATH=.../master/instdir/program \
.../master/workdir/LinkTarget/Executable/unoidl-read --published \
.../libreoffice-6.4.0.3-buildfix1/instdir/program/types.rdb \
.../libreoffice-6.4.0.3-buildfix1/instdir/program/types/offapi.rdb \
>.../master/offapi/type_reference/offapi.idl
as "no changes", so I redid that part correctly now:
* plus manual fixup by re-applying offapi/type_reference/offapi.idl part of
214e6caf2c "[API CHANGE] remove BasicImport UNO
interfaces"
Change-Id: If58251331c1b379a04bf0c60dfffc2ffb0f6bc6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89565
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
which are unused since
commit 4e97fa0f4e
Date: Thu Feb 20 13:09:32 2020 +0200
use fast-parser APIs for embedded script parsing
and highly unlikely to be externally used since they parse document
internal script code.
Change-Id: I2e0e237fb31bba85f1ef63c88f3a6959eedf2ca7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89104
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
LD_LIBRARY_PATH=.../master/instdir/program \
.../master/workdir/LinkTarget/Executable/unoidl-read --published \
.../libreoffice-6-1-0/instdir/program/types.rdb \
>.../master/udkapi/type_reference/udkapi.idl
* no changes
LD_LIBRARY_PATH=.../master/instdir/program \
.../master/workdir/LinkTarget/Executable/unoidl-read --published \
.../libreoffice-6-1-0/instdir/program/types.rdb \
.../libreoffice-6-1-0/instdir/program/types/offapi.rdb \
>.../master/offapi/type_reference/offapi.idl
* all the interim modifications to offapi/type_reference/offapi.idl were done in
error and had already been reverted again (i.e., `git diff
76f30450577bcecf0423833884e3e5215decdd07..5b0ceb86c342754d8f4e83408c7ae0da0e3931d3^
-- offapi/type_reference/offapi.idl` is empty)
Change-Id: Ibac6d00f9b6fa3fa4d4ac491af66ea4938b36b87
Reviewed-on: https://gerrit.libreoffice.org/63424
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts the reordering of properties and adds new properties
to the end and marks them as optional so we break API as little as
possible.
Change-Id: I422d882d1d1c721dd3ff7ad289329a9df58beb42
Reviewed-on: https://gerrit.libreoffice.org/54322
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
Had been added as part of 7a8ed362eb "[API CHANGE]
revert and deprecate *BackGraphicURL add *BackGraphic", for no apparent reason.
(Will eventually be added with a "Update the reference rdbs to
libreoffice-6-1-0" commit.)
Change-Id: If6c0405df91accc52a67ad62d7ee7dfb49a4c569
Reviewed-on: https://gerrit.libreoffice.org/53981
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
*BackGraphicURL include the following properties:
- BackGraphicURL
- FooterBackGraphicURL
- HeaderBackGraphicURL
- ParaBackGraphicURL
This were removed, but for backwards compatibility this commit
adds them back again and depreactes them in the UNO API. The
behaviour also changes as internal vnd.sun.star.GraphicObject
scheme URLs aren't supported so this properties can only be set
and only if a external URL is provided. If getting such a property
then a RuntimeException will be thrown.
[ Miklos Vajna: fixed up sw/qa and writerfilter bits. ]
Change-Id: If60011837da96197b576bfe2671ecafccad736c7
Reviewed-on: https://gerrit.libreoffice.org/53511
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Use Migration warn dialog directly in library dba instead of popping up
window in dbu and passing down the information through XDataSource.
Change-Id: I6b8d2b55408a741662052d4af316b0c662d799f0
Reviewed-on: https://gerrit.libreoffice.org/53363
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Bunth <btomi96@gmail.com>
Revert the state of GraphicURL property so it supports setting a
external URL, but getting throws and exception.
Modify the Graphic property, so it reflects what was used with
GraphicURL before.
Change-Id: Ia05b8ea37997b5ed8c75215557cce9979630c898
Reviewed-on: https://gerrit.libreoffice.org/53509
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Warn user with a pop-up dialog before migration.
To do that we have to know the database URL at UI level. In order to get
that I updated XDataSource interface with getConnectionURL().
The dialog offers two options: proceed with or without migration. If the
user choose "yes", we store that information in XDataSource. The
migration itself will be made in buildLowConnection().
Change-Id: I1f0d03da6352f7a0a8d989da79c4b2fe60a03ca1
Reviewed-on: https://gerrit.libreoffice.org/52876
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Bunth <btomi96@gmail.com>
LD_LIBRARY_PATH=.../master/instdir/program \
.../master/workdir/LinkTarget/Executable/unoidl-read --published \
.../libreoffice-5-4-0/instdir/program/types.rdb \
>.../master/udkapi/type_reference/udkapi.idl
* no changes
LD_LIBRARY_PATH=.../master/instdir/program \
.../master/workdir/LinkTarget/Executable/unoidl-read --published \
.../libreoffice-5-4-0/instdir/program/types.rdb \
.../libreoffice-5-4-0/instdir/program/types/offapi.rdb \
>.../master/offapi/type_reference/offapi.idl
* plus manual fixup for now by re-applying offapi/type_reference/offapi.idl part
of 00657aef09 "migrate to boost::gettext"
Change-Id: Iecebe43043ee2518a371b60795737436bbcb0941
* 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
Quick solution before 5-3 branch off without reverting everything related.
This will need a new constant value type for API instead of the enum and an
internal mapping from/to the enum.
Kept the GeneralFunction_MEDIAN at all places in uing code so it can be
easily grep'ed for.
Change-Id: I95256649f16ded08e467003d2924be0ff5efb87f
(This deliberately leaves out the published
css.mozilla.XRemoteServiceManagerProvider originally manually removed from
offapi/type_reference/offapi.idl with 4c18af27bf
"tdf#96398 kill remaining NPAPI support for plugins _inside_ LO" and now fully
removed with b558997012 "[API CHANGE] Remove
tdf#96398 leftover XRemoteServiceManagerProvider".)
Change-Id: I75d4cd82ba306099e2563a44739bfb3867a265e9
- probably out of date
- links against Gtk2 and thus causes a GTk2 dependency in core packages
- the only serious usecase (Flash) is doomed anyway
Change-Id: I7264ab5eb04c2f4b6c31a815e45b9818209e5ae2
Reviewed-on: https://gerrit.libreoffice.org/20658
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Reviewed-by: Bryan Quigley <gquigs@gmail.com>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
In order to use GetSelectedFiles (in XFilePicker2) instead of GetFiles (in XFilePicker),
here are some api changes
before:
XFilePicker3 inherits from XFilePicker
XFilePicker2 is not a published interface
after:
XFilePicker3 inherits from XFilePicker2
XFilePicker2 is a published interface
+ adapt Uno Implementations
Change-Id: If44afaa7236f08bc2b814f91eda5bfad333dd799
Reviewed-on: https://gerrit.libreoffice.org/17068
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
..in 9ed1dd01be "tdf#90839: support for wrapped
text in data labels and for centered data value" by moving the additional
optional property to the end; also, add missing @since tags
Change-Id: I6f8a6cb22d29ba27a109089892b8df009d1043db
Now in a pie chart the text of a label can be wrapped, the wrapping is
automatic and the maximum text width is fixed to almost half the pie
radius. This feature is used to import correctly the relative text
wrapping property provided by MSO.
Moreover the data value and percent value of a label are now centered
horizontally, respect with the label text.
Conflicts:
chart2/qa/extras/xshape/chart2xshape.cxx
Change-Id: Ie10d6184365436f763cd9693a5bbefcfa9b3862b
Reviewed-on: https://gerrit.libreoffice.org/17193
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
...from 9835bb562c "MM: export the SwDocShell mail
merge via UNO." It shall only be edited manually when deliberately going
incompatible.
Change-Id: I19c82dca3b6537631a155629d6072b516b32ded5
This saves the loading time for large document. Use it if you
want to present the generated document to the user or write a
mail merge unit tests.
This includes:
* renaming "only" to "shell" at multiple occurences
* dropping the DBMGR_MERGE_SINGLE_FILE special type for the mail
merge wizard in favour of an additional SwMergeDescriptor
boolean
* cleanup and renaming of the internal merge type enums, so these
actually match the diffferent merge targets: printer, email,
file and shell
Change-Id: I33c6773972195193687ba9c3e12b562310d330c1
This reverts the part of 4452ac2322 "Fix hungarian
prefix for calendars" that needlessly changed a method parameter name in
published UNO API, which is, strictly speaking, incompatible.
Change-Id: Icd1ee34d200ebab01010d5dd35a1b19c47bfc05a
...incl. some /** @deprecated */ that had inadvertently been missing from the
original unoidl-read output, and re-apply the fix from
09f9a79b11 "[API CHANGE] fix endCDATA to allow
throwing css::xml::sax::SAXException."
Change-Id: I5f9001e0cf05ec6cd950011ab307b71811f1a2e1
...and the hack to locally introduce a bogus pupblished forward declaration of
XFormOperations with which this has been worked around in
cf5c369123 "INTEGRATION: CWS dba23b: work around
idlc limitation, which does not allow to refer unpublished interfaces as
optional entities in published services" no longer works in
offapi/type_reference/offapi.idl.
So given FormController is a (deprecated, even) old-style service (i.e., little
more than glorified commentary), the best fix probably is to demote the
problematic optional property to a comment.
Change-Id: Ia38483c817dc1762ba73315abcd4f9f063db3093
Stephan Bergmann