Age | Commit message (Collapse) | Author |
|
Introduce readModel(), readModelStream(), insertModel(), insertModelStream()
in Gallery Binary Engine because these deal with file reading stuff.
Move ImplGetURL() to galmisc for now because
GalleryTheme and GalleryBinaryEngine both use it.
Separate InsertModel() into two parts - one dealing with Sot Storage stream,
the other adding object to gallery list. Move first part to Gallery Binary
Engine, the second stays.
Separate InsertObject() into two parts.
Move CreateThemeEntry() to Binary Engine.
Change-Id: Id3b4091db27b5b88bcf025f9fd94ad86169505d0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98492
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This reverts commit 1a6397030381a45f27ab7a2a02e6e6d0f9987c84.
Change-Id: Iaa706bb4ea3144ef57ab359b982400abc589b97e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90454
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Using SVX_DLLPUBLIC for both Library_svxcore and Library_svx had started to
cause failures with clang-cl on Windows now, presumably due to devirtualization:
> linectrl.o : error LNK2001: unresolved external symbol "protected: virtual void __cdecl SvxMetricField::DataChanged(class DataChangedEvent const &)" (?DataChanged@SvxMetricField@@MEAAXAEBVDataChangedEvent@@@Z)
> linectrl.o : error LNK2001: unresolved external symbol "protected: virtual bool __cdecl SvxMetricField::PreNotify(class NotifyEvent &)" (?PreNotify@SvxMetricField@@MEAA_NAEAVNotifyEvent@@@Z)
> linectrl.o : error LNK2001: unresolved external symbol "protected: virtual bool __cdecl SvxMetricField::EventNotify(class NotifyEvent &)" (?EventNotify@SvxMetricField@@MEAA_NAEAVNotifyEvent@@@Z)
> linectrl.o : error LNK2001: unresolved external symbol "protected: virtual void __cdecl SvxMetricField::Modify(void)" (?Modify@SvxMetricField@@MEAAXXZ)
> linectrl.o : error LNK2001: unresolved external symbol "private: virtual bool __cdecl SvxFillAttrBox::PreNotify(class NotifyEvent &)" (?PreNotify@SvxFillAttrBox@@EEAA_NAEAVNotifyEvent@@@Z)
> linectrl.o : error LNK2001: unresolved external symbol "private: virtual bool __cdecl SvxFillAttrBox::EventNotify(class NotifyEvent &)" (?EventNotify@SvxFillAttrBox@@EEAA_NAEAVNotifyEvent@@@Z)
> C:\lo-clang\core\instdir\program\svxcorelo.dll : fatal error LNK1120: 6 unresolved externals
Replacing certain uses of SVX_DLLPUBLIC with the newly introduced
SVXCORE_DLLPUBLIC (include/svx/svxdllapi.h) has been done on Linux as follows:
> git grep -w --line-number -e SVX_DLLPUBLIC --and --not -e '#define SVX_DLLPUBLIC' >LINES
to produce a file LINES containing all 640 uses. (Conveniently, all uses
happen to be on different lines.) Manually create a file TOKENS
with 640 corresponding lines, each containing the (class or function) name that
is made SVX_DLLPUBLIC by in the corresponding line in LINES. Then
> nm -D --def instdir/program/libsvxcorelo.so | grep -ivw '[vw]' | c++filt >SVXCORESYMS
> nm -D --def instdir/program/libsvxlo.so | grep -ivw '[vw]' | c++filt >SVXSYMS
> n=$(cat TOKENS | wc -l)
> for ((i=1;i<="$n";++i)); do
> tok=$(head -n "$i" TOKENS | tail -1)
> printf @
> grep -Fw "$tok" SVXCORESYMS >/dev/null && printf svxcore
> printf @
> grep -Fw "$tok" SVXSYMS >/dev/null && printf svx
> printf '@ '
> head -n "$i" LINES | tail -1
> done
to generate 640 output lines detailing for each SVX_DLLPUBLIC name occurrene
whether it is mentioned in exports from neither (@@@), only from svx (@@svx@),
only from svxcore (@svxcore@@), or from both libraries (@svxcore@svx@). The
numbers that gives is
10 @@@
180 @@svx@
424 @svxcore@@
26 @svxcore@svx@
The 10 @@@ ask for follow-up clean up, but most of them are just left as
SVX_DLLPUBLIC for now. The exceptions are sxv::ITextProvider
(include/svx/itextprovider.hxx) and SdrCustomShapeGeometryItem::PropertyPairHash
(include/svx/sdasitm.hxx, where PropertyPairHash is a member struct of
SVXCORE_DLLPUBLIC SdrCustomShapeGeometryItem). Keeping them as SVX_DLLPUBLIC
would cause "unresolved externals" errors when linking Library_svxcore on
Windows.
The 180 @@svx@ are fine to keep as-is, and the 424 @svxcore@@ need rewriting.
The 26 @svxcore@svx@ needed manual inspection to decide (in some cases, the
chosen name in TOKENS was a too generic function name like Fill, in other cases
it was the name of a class exported from one library but also mentioned in the
arguments of a function exported from the other).
And for sdr::table::SdrTableObj the class itself is defined in svxcore while the
static member functions ExportAsRTF and ImportAsRTF are defined in svx. But
MSVC does not allow to mark the class as SVXCORE_DLLPUBLIC and the two static
member functions as SVX_DLLPLUBIC, so move the two functions out of the class.
(There appears to be no real necessity that they were static member functions in
the first place; they don't even need to be friends of the class. Nevertheless,
this mixture of functionality from svxcore and svx in include/svx/svdotable.hxx
may ask for follow-up clean up, one way or another.)
All the output lines that need rewriting (all the @svxcore@@ ones, and the
manually picked subset of @@@ and @svxcore@svx@ ones) are copied into a new file
CHANGE (containing 451 lines). Then
> sed -E -e 's|^@.*@.*@ ([^:]+):([0-9]+):.*$|sed -i -e "\2 s/SVX_DLLPUBLIC/SVXCORE_DLLPUBLIC/" \1|' <CHANGE >COMMANDS
> . COMMANDS
to do the changes.
Change-Id: If9b6dd1c9e9ba2eb883dbdac4385d28c6fc8a203
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87794
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic2212a502bbd42217934884f4fce49f6f8d4765c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87236
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4aebb3f90e9943044d106a507972c39434988f03
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87003
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If55e51b8627083ba3ece2b3270adb47668b25e9d
Reviewed-on: https://gerrit.libreoffice.org/81705
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I861d3f0fa15ee3b7e0e830c4fac2e5794ea4071b
Reviewed-on: https://gerrit.libreoffice.org/72213
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Change-Id: Ie37288e4b9f064e309df81830f3a07507525bc55
Reviewed-on: https://gerrit.libreoffice.org/66771
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If4149e8b4a6e58f89997b150cc81e2e1195be4da
Reviewed-on: https://gerrit.libreoffice.org/64567
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I04a146d3d8a428ac1678827dc883525c40240a44
Reviewed-on: https://gerrit.libreoffice.org/62787
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I643e8686e015ca85dd96221f1c93038f4fddf27b
Reviewed-on: https://gerrit.libreoffice.org/61182
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2e34b3819c576072beaacb87cb99d73457667dc3
Reviewed-on: https://gerrit.libreoffice.org/54449
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iad9ca26bb94fb1d499d3ce028b2289c11c1771fa
Reviewed-on: https://gerrit.libreoffice.org/53711
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
when we see a unaryoperator, unless it's one of a small set, we can
know (mostly) that the field will not be written.
there is still a small risk of false+ with code taking references
via conditional expressions.
Change-Id: I96fa808067576a50e5eaf425338e225b4e0bdd4e
Reviewed-on: https://gerrit.libreoffice.org/53263
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia58d8950b3b9e48bbe9f075b9fe1eed62d9abf0d
Reviewed-on: https://gerrit.libreoffice.org/53188
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iffe047b081fde0bb582d8730a8e96d2597c7567a
Reviewed-on: https://gerrit.libreoffice.org/52780
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6e72fbe44dcb65ee5162448e9a72e6437d56b044
Reviewed-on: https://gerrit.libreoffice.org/50948
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to match the underlying field
Change-Id: I96bee1b19fb33e00bb09617a458f741654beb7f3
Reviewed-on: https://gerrit.libreoffice.org/46479
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I50528411bb76d5a204a5e52c4d77a7ecaf7f5ddf
Reviewed-on: https://gerrit.libreoffice.org/46390
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to match the underlying type on mxProgressBar->setValue
Change-Id: Ib04569235830f16b6507180e0f27816f8cfc50ff
Reviewed-on: https://gerrit.libreoffice.org/46347
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Do not try to squeeze it into such.. especially if
SotClipboardFormatId::... enum identifiers are used in a user
object id context that is completely not related to the identifier
name this is totally confusing.
commit fb14be5f8f74f83ba89e15f891ddf1f753dcc62f
Date: Thu Mar 12 14:53:28 2015 +0200
create new 'enum class' SotClipboardFormatId to unify types
overdid with that.
Change-Id: I34b570be9f52b7b94ca8af6b23983393ac3a3a55
Reviewed-on: https://gerrit.libreoffice.org/44612
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I74296e2185902498cd569ecde83905f718a41e84
Reviewed-on: https://gerrit.libreoffice.org/43715
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I899a8126c9d971601fea6c77eca165718aea0ac5
Reviewed-on: https://gerrit.libreoffice.org/41237
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
ever since
commit ddb1d5ebf0a81888001ffa1dbab883df70cdc279
Author: Felix Zhang <fezhang@suse.com>
Date: Fri Nov 18 18:23:52 2011 +0800
remove unused Sdr methods
removed the SdrObjFactory::MakeNewObjUserData method
Change-Id: I95c167b2f20b436bcc0085b6b616406ac210045f
Reviewed-on: https://gerrit.libreoffice.org/40363
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
* 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>
|
|
Change-Id: Ie3795870484648e62dea483f9976af31cd1be167
Reviewed-on: https://gerrit.libreoffice.org/37006
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I10c712f7be1247055f7bd28b25fdd6950da9d50b
|
|
Change-Id: I658ac9675b993bdea46296833f715947056ed9b7
|
|
Change-Id: I7feed30eea4f7367943fa2d6e0d75be5ca209068
Reviewed-on: https://gerrit.libreoffice.org/33516
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
SW_DRAWLAYER had the same value as SC_DRAWLAYER, so I merged it into the
ScOrSwDraw enum constant
Change-Id: I5c45d378c00364d11cc960c9e48a6e3f10928724
Reviewed-on: https://gerrit.libreoffice.org/31037
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which can be replaced with using declarations.
Is there a more efficient way to code the search? Seems to slow the
build down a little.
Change-Id: I08cda21fa70dce6572e1acc71bf5e6df36bb951f
Reviewed-on: https://gerrit.libreoffice.org/30157
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...which was introduced with 3ead3ad52f9bb2f9d1d6cf8dfc73a0a25e6778ed "Gradually
typed Link" to distinguish the new, typed versions from the old, untyped ones,
but is no longer necessary since 382eb1a23c390154619c385414bdbe6f6e461173
"remove untyped Link<>" removed the old versions.
Change-Id: I494025df486a16a45861fcd8192dfe0275b1103c
|
|
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "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
|
|
Change-Id: I1bc1244646db661f181d4224d81f12d613976362
|
|
passing params by setting fields on yourself is just gross
Change-Id: Iee98a9e8e266b56fc886c76eab470ab1ff7ff8e4
|
|
Change-Id: Iacd4ed12c6c5dfdc2f31f85c8c1ce2cee8a8641f
|
|
Change-Id: I99e3d6137ec17e3fc782253c85e5fa4f1da4cec4
|
|
Change-Id: I45895e9845a9037da207f001fece427452ed499f
|
|
Change-Id: I71682f28c6a54d33da6b0c971f34d0a705ff04f5
|
|
Change-Id: I9cd92b53370a6b6018d2f7c648890f9c014a27de
|
|
Change-Id: I2ea407acd763ef2d7dae2d3b8f32525523ac8274
|
|
Change-Id: I184d836e944d6dcfd17233a7a83680f1c1bff9bf
|
|
Change-Id: Ib27854a8470f3ff5b208cb949a7bd02f2a86c969
|
|
Change-Id: I242cd126814bbebdb99ea38d9e66513189c313d9
|
|
Change-Id: If7652a7c0251b741660365848a717c06954ca419
|
|
Change-Id: I544e1154c846a8b5da4ab3dee72e3aa1332557e6
|
|
Change-Id: I4e33f2ebfc00d9c5c75ddbb0625aaf7c39802e7f
|
|
Change-Id: I5c80b8b762682bc666761710039b3b57bb3d579d
|
|
of which there are several.
There are some issues here I am unsure of
- the SW and SC and CHART2 modules essentially ignore the enum values and assign their own ids
Perhaps I should change them to use the common values and create new enum values where necessary?
- the sc/qa/ and sq/qa/ and starmath/qa/ code was doing some dodgy stuff. I translated the code to pass down the stuff
numeric values to the underlying code, but perhaps further fixing is necessary?
Change-Id: Ic06d723e404481e3f1bca67c43b70321b764d923
|