this modifies codemaker so that, for an UNO enum, we generate code
that effectively looks like:
#ifdef LIBO_INTERNAL_ONLY && HAVE_CX11_CONSTEXPR
enum class XXX {
ONE = 1
};
constexpr auto ONE = XXX_ONE;
#else
...the old normal way..
#endif
which means that for LO internal code, the enums are scoped.
The "constexpr auto" trick acts like an alias so we don't have to
use scoped naming everywhere.
Change-Id: I3054ecb230e8666ce98b4a9cb87b384df5f64fb4
Reviewed-on: https://gerrit.libreoffice.org/34546
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Mostly generated using
make check COMPILER_EXTERNAL_TOOL=1 CCACHE_PREFIX=clang-rename-wrapper RENAME_ARGS="-qualified-name=Rectangle -new-name=tools::Rectangle"
Except some modules have their own foo::tools namespace, so there have
to use ::tools::Rectangle. This commit just moves the class from the
global namespace, it does not update pre/postwin.h yet.
Change-Id: I42b2de3c6f769fcf28cfe086f98eb31e42a305f2
Reviewed-on: https://gerrit.libreoffice.org/35923
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
We should always be clear and precise, given that LibreOffice handles various
kinds of links.
Nobody at L10n wanted this change, but they were ignored.
This should fix tdf#103093, which was a consequence of the introduced ambiguity.
This reverts commit a1297fc2df.
Change-Id: I29232c7a8384c3fa501c61aab26e061ebcb1a0d8
Based on the casts in chart2/source/view/main/ChartView.cxx
and the similarity of naming of values, I conclude that this
enum was intended to abstract over css::text::WritingMode2.
Added a comment to that effect.
Change-Id: I3af8bbe8b6ac8c4a9375f6ccde145b98b9c69a57
Reviewed-on: https://gerrit.libreoffice.org/35164
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(vs. uses of sal_uInt16 representing such items' IDs). APPEND and ITEM_NOTFOUND
are members of ToolBox now (and have been bumped to the corresponding type's
max). The payload of VclEventIds
ToolboxButtonStateChanged
ToolboxClick
ToolboxHighlightOff
ToolboxItemAdded
ToolboxItemDisabled
ToolboxItemEnabled
ToolboxItemRemoved
ToolboxItemTextChanged
ToolboxItemUpdated
ToolboxItemWindowChanged
ToolboxSelect
has been changed too (note that reading/writing of those payloads isn't very
consistent, though: for some of these, values are written that are never read,
while for some others no values are ever written but the reading code would like
to receive some value if the payload wasn't a nullptr).
Change-Id: I4856ffb3637404b8d866621a3503d7922b1b8141
...from function definitions occurring within class definitions. Done with
a rewriting Clang plugin (to be pushed later).
Change-Id: I9c6f2818a57ccdb361548895a7743107cbacdff8
Reviewed-on: https://gerrit.libreoffice.org/34874
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
and related css::util::SearchOptions2
The TransliterationModules enum has it's constants spread over multiple
UNO enum/constant-collections - TransliterationModules and
TransliterationModulesExtra, which means that most code simply uses
sal_Int32.
Wrap them up into a better bundle so that only the lowest layer needs to
deal directly with the UNO constants.
Change-Id: I1edeab79fcc7817a4a97c933ef84ab7015bb849b
Reviewed-on: https://gerrit.libreoffice.org/34582
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
INetMIMEEncodedWordOutputSink had been intended to encode (non-ASCII) content of
a "free-form text" header field as per RFC 2047. It used a heuristic trying to
detect already encoded words (=?...?...?...?=) in the input, to pass them
through unmodified. (Arguably, it could just as well have encoded them,
assuming they were meant to be genuine input.) However, that heuristic had a
bug ever since 8ab086b6cc "initial import", going
from STATE_FIRST_EQUALS to STATE_FIRST_EQUALS instead of STATE_FIRST_QUESTION,
rendering the heuristical detection logic effectively unused.
Instead of fixing the bug, 6e12729f71 "remove
unused enumerator from EncodedWordState" and
b8d8fb3f0c "convert EncodedWordState to scoped
enum" crippled the code further by removing any reputedly unused cases.
But the only remaining use of INetMIMEEncodedWordOutputSink is in
INetMIMEMessage::SetHeaderField_Impl, encoding MIME-Version, Content-Transfer-
Encoding, Content-Type, and Content-Disposition header fields. And none of
those headers have any "free-form text" content that should be encoded as per
RFC 2047. The first two have fixed ASCII-only content ("1.0" and "7bit",
"8bit", etc., respectively), while the latter two have structured content that
may contain parameters of arbitrary content, which must be encoded according to
RFC 2231 (but currently isn't).
And the only place where such arbitrary-content parameters are generated is in
the two calls to SetContentTransferEncoding in
forms/source/component/DatabaseForm.cxx. (The calls to SetContentType there and
in tools/source/inet/ itself are all known to have unproblematic ASCII-only
content.) So mark those two places with TODOs about the missing encoding (which
had been missing since forever) and, in INetMIMEMessage::SetHeaderField_Impl,
liberally convert the content to 8-bit via OUString::toUtf8 for now.
Change-Id: I4b2a219b396953b219ca66441a5227157a35951f
This reverts commit e387b69967.
It breaks toolkit.subsequentcheck with
propertyChangeListener wasn´t called for ´TypedItemList´
Back to the drawing board for the twisted property logic of forms and
toolkit uno control models.
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Noel Grandin