Age | Commit message (Collapse) | Author |
|
i.e., css::uno::Any function template specializations
Any::has<Any>() const
Any::get(Any const &) const
operator >>=(Any const &, Any &)
operator <<=(Any &, Any const &)
that don't make much sense (the first is always true, the rest can be replaced
with operator =, which additionally supports move semantics). For 3rd-party
compatibility, do this only for LIBO_INTERNAL_ONLY, however.
However, some generic template code did benefit from operator >>= working also
for Any, so make up for that with a new (LIBO_INTERNAL_ONLY, given that
operator >>= still covers if fine for !LIBO_INTERNAL_ONLY) fromAny,
complementing the existing toAny.
Change-Id: I8b1b5f803f0b909808159916366d53c948206a88
Reviewed-on: https://gerrit.libreoffice.org/30022
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Id2dbbf384637223db3d334d95332251832918003
Reviewed-on: https://gerrit.libreoffice.org/30927
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib34e14806f7cc9a97ecfd68687ab17ee5c1f022b
Reviewed-on: https://gerrit.libreoffice.org/30652
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This has been wrong since the initial commit...
Change-Id: I271375ba10c37aa9b198476955d66af9fc019e27
|
|
This makes simple (i.e., not implemented as a shader) OpenGL transitions
work correctly again.
Change-Id: I773f686089bce3611940743b1a7f5046093886e8
|
|
Change-Id: I3a7207e0566bc4b871b364da3180ce67e1099de8
|
|
Change-Id: I894e6a089e99ed6cec3a970ffa0cce9cbd9a9e1a
|
|
Change-Id: I57b8d8b187fe7b8a99f2f90d696cd8c97b8a07b6
|
|
Change-Id: Iaf10935d8f231676333018a5954d97defe35acf6
|
|
Change-Id: Ia4c411f5a9a68c2f344188ce6b6bc1815c89f993
Reviewed-on: https://gerrit.libreoffice.org/30055
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
anywhere anyone wanted to Get[Font|Color] give it the Label
ones instead.
why this is exposed through uno is bewildering, stubbed those
out for the moment
Change-Id: I7a31d027287436be1c075c76a370047efd010bf3
|
|
I left a prefix on the names "Map" so that I would not have to re-arrange
each name too much, since I can't start identifiers with digits like "100thMM"
And remove RSC_EXTRAMAPUNIT, which doesn't seem to be doing anything anymore.
Change-Id: I5187824aa87e30caf5357b51b5384b5ab919d224
Reviewed-on: https://gerrit.libreoffice.org/29096
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I70fcf95dfd3db05b4fd6e5cee37866f673d3afa8
Reviewed-on: https://gerrit.libreoffice.org/29183
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... except in include/rtl, include/sal, include/uno, where sal_Size is
retained for compatibility, and where callers of rtl functions pass in
pointers that are incompatible on MSVC.
Change-Id: I8344453780689f5120ba0870e44965b6d292450c
|
|
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: I136423c105316c9b5b18e64d04a248fd7ac5590b
|
|
Change-Id: I1e447f5eccb41325d96e9c4cb1598a05e702badc
|
|
Change-Id: I26f46ddac3d7d810ebfa1c3e7f1a77427369828e
Reviewed-on: https://gerrit.libreoffice.org/28451
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ia01f3a9aa21c88df5fe5242ad4a3c0acbe68fda0
Reviewed-on: https://gerrit.libreoffice.org/27903
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I553d1b031b8d261a1caa8b77a8d687af21a6f8d6
Reviewed-on: https://gerrit.libreoffice.org/27672
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I4258bcc97273d8bb7a8c4879fac02a427f76e18c
Reviewed-on: https://gerrit.libreoffice.org/27317
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I28236dd0c7dbd4e1798055229b2db2d0101a493e
|
|
Change-Id: If898ac15d958d4f0a5bcf0062a8d9869ef5e84e5
|
|
The setScene() function was a hack from the beginning--it was only
introduced to avoid the need to override displaySlides_() in
DiamondTransition. And it worked until someone started to make false
assumptions about the scene, like that it is unchanging or that both
slides have the same (non-zero) number of elements...
Change-Id: I401cccc4dfbcba0a5f5544d3aac94d1cae027c99
|
|
Change-Id: Iaeeb594821f8b2875ca08afdf62d442d33e186ba
|
|
Use parentheses to clarify the code.
Change-Id: I864dc6dacadb5b9ba9dca8e0abd9fa4e6db1eddc
Reviewed-on: https://gerrit.libreoffice.org/25677
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ia0d8f463a4dba9ec63aa0159441e3e607dd3bf5e
Reviewed-on: https://gerrit.libreoffice.org/26738
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Committer's note: There is no Oval or Ellipse transition in MSO formats,
so fallback to circle on export to those.
Change-Id: Ibc3d617d3bb94bdd0702bb4d60ce5fbe2eea8e24
Reviewed-on: https://gerrit.libreoffice.org/23661
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
The patch caused problems with the export filter tests, to check that you need to add --with-export-validation to your autopen.input
see https://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/export-validation for more info on how to set it up
This reverts commit 248c5ea771255b54e64394458a321ccf829bbd02.
Change-Id: Ib3b8fa7bf80630feeca1f24dfb1ceb5a945d7162
Reviewed-on: https://gerrit.libreoffice.org/26114
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: Ibc3d617d3bb94bdd0702bb4d60ce5fbe2eea8e24
Reviewed-on: https://gerrit.libreoffice.org/23661
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: I76843139e43ca1c158a977e24d210d5af93e4d0f
Reviewed-on: https://gerrit.libreoffice.org/26014
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I55c2a95a860dc814569b00c2edc9e135feb95bcd
|
|
Change-Id: Ieed5f4d9411478d2568b8e5f4bbe0782bd1d309d
Reviewed-on: https://gerrit.libreoffice.org/25724
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
...reportedly available since Boost 1.34, and configure.ac checks for at least
Boost 1.47.
Change-Id: I07952de220f1eee5f91ad83a1965420eb6b09ada
|
|
to never takes any value other than NORMAL
Change-Id: I9558ee8864537c695ce1172a0cfad421d5f591ee
Reviewed-on: https://gerrit.libreoffice.org/25587
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I1fd09a729cbda00f99841532e0dd3fa66bce7bea
Reviewed-on: https://gerrit.libreoffice.org/25534
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I00ecc510192e71b12f746f876d564ac9b7c3a6c5
|
|
Change-Id: Ied221b25f1bbe486cac6bb88bbc752a3c19c33ce
|
|
and drop unused FULL value
Change-Id: I3b9c26cb164785ef86f1a8d57cce962b015c85d6
Reviewed-on: https://gerrit.libreoffice.org/25432
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
slideshow mbHasTFPVisual is always false since
commit eccaf91ec9c50d42ce98c90abe2c129bedbbc60e
Date: Mon May 19 19:21:29 2014 +0200
use VCL's OpenGLContext for 3D transitions
Change-Id: I510518461eb8bc9669d0de2679c34c473f66b175
and GLWindow fbc has always been null since that incarnation of opengl started,
so even if mbHasTFPVisual was true it would crash.
OpenGLHelper::GetPixmapFBConfig is *almost* the same as the old removed code
for setting fbc, but if I use that then for me the transitions still don't work
at all.
Examining further shows GetPixmapFBConfig lacks the test for
GLX_BIND_TO_MIPMAP_TEXTURE_EXT that the old code had.
If I add than, then it "works", but examining *that*, reveals it only works
because GLX_BIND_TO_MIPMAP_TEXTURE_EXT is unsupported on my rig, so the
GLX_EXT_texture_from_pixmap code still doesn't get executed.
I apparently can't test the original working configuration, and I'm not
particularly interested in getting X working and I just wanted to make sure I
didn't break that case, so...
this removes the uncallable since 2014 code entirely rather than try to
fix it.
I suspect this may leave the cairo-canvas CanvasBitmap::getFastPropertyValue
"1" branch now also dead
Change-Id: I6727576056533fa54a4f82378954fb53891f5873
|
|
which, at least theoretically, allows there to be vclplug
specific ones. i.e. a gtk3 specific one which doesn't
assume gtk3 is running under X
Change-Id: I6c007a87abbd3049b6fffc70d349e3b7ac445eec
|
|
Change-Id: Icf0056e13c88d7d347e668adaeddd4ed72af85cf
Reviewed-on: https://gerrit.libreoffice.org/25141
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I3fa866bfb3093fc876474a9d9db29fe05dc2af3a
Reviewed-on: https://gerrit.libreoffice.org/25056
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I0b02b2b13cacac48d94e541671a446368f5e527f
Reviewed-on: https://gerrit.libreoffice.org/24885
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Mac OS X clang/libc++ refuse to invoke a "const" std::mem_fn object.
And you thought that MSVC was the only one with a deficient stdlib.
Change-Id: Ib7a659adbd270a20b9fdcd661df1bd78d40768ca
Reviewed-on: https://gerrit.libreoffice.org/24901
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Pretty sure FuncT(...value_type) is wrong since value_type is
std::weak_ptr which does not implicitly convert to a callable pointer;
this caused build failure on Mac OS X with clang/libc++.
Change-Id: Id9de4a7825347a84cce2aab5367a457a003bb352
|
|
A bit more verbose but we have less than 10 mem_fn now so better
elimintate them all so hopefully we can get rid of the corresponding
boost warning patches.
Change-Id: I79e2f9994841125916d92bdce9973d956f2a68ce
|
|
Change-Id: I98229d14109cf243839d632feabde1391ea9bad5
Reviewed-on: https://gerrit.libreoffice.org/24847
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
...which (in LIBO_INTERNAL_ONLY) for Clang expands to [[clang::fallthrough]] in
preparation of enabling -Wimplicit-fallthrough. (This is only relevant for
C++11, as neither C nor old C++ has a way to annotate intended fallthroughs.)
Could use BOOST_FALLTHROUGH instead of introducing our own SAL_FALLTHROUGH, but
that would require adding back in dependencies on boost_headers to many
libraries where we carefully removed any remaining Boost dependencies only
recently. (At least make SAL_FALLTHROUGH strictly LIBO_INTERNAL_ONLY, so its
future evolution will not have any impact on the stable URE interface.) C++17
will have a proper [[fallthroug]], eventually removing the need for a macro
altogether.
Change-Id: I342a7610a107db7d7a344ea9cbddfd9714d7e9ca
|
|
Change-Id: I38fde54d0fdbb9c61e3df004242a70e14429f52f
|