Reduce potential confusion with the global tools namespace. Will
hopefully make it possible to remove the annoying initial :: when
referring to the global tools namespace. Unless we have even more
tools subnamespaces somewhere.
Thorsten said it was OK.
Change-Id: Id088dfe8f4244cb79df9aa988995b31a1758c996
Reviewed-on: https://gerrit.libreoffice.org/42644
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
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>
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
and remove the casting silliness, allowing the removal of
cairo_cairo.?xx
If anything is to go wrong I'd guess it'll be the windows directx stuff.
Change-Id: I3e22c07b9c26ade9b27a245fdd8408de540643f4
anyplace calling GetSystemChildSystemData on a SystemChildWindow is definitely
right
anyplace calling GetWindowSystemData on a Window *might* have intended to call
GetSystemChildSystemData on a Window casted back to an underlying
SystemChildWindow.
Change-Id: I7dcf3a50d0b7ed29bc08cfdb15cc0dcb86be8fa7
Reviewed-on: https://gerrit.libreoffice.org/25158
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
This reverts commit d01f7db4b5.
Revert "tools: replace BOOST_CURRENT_FUNCTION with __func__"
This reverts commit 1030305406.
Surprisingly MSVC 2013 does not support __func__ - need 2015.
Change-Id: I7084d7b79784b34a8f40fb986d10ffefbabae7fb
Previously we would get an explicit ~OpenGLContext - and potentially
leave FMR's around for other OGC users, now we treat the other users
properly - we need an explicit dispose() to get Window::dispose ordering
right.
Change-Id: I5edcbd73399b6db3dbcfb391570f364f9ab0c70d
Reviewed-on: https://gerrit.libreoffice.org/18412
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Replace ::std::for_each for a more readable range-based for loop in
cases in which the function object to be applied by for_each is more
readable as the body of a for loop.
Change-Id: I5ea0f6a464855b8cc8af38f211bb784dd91eca0d
Reviewed-on: https://gerrit.libreoffice.org/17775
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
in preparation to kill --enable-verbose in configure.ac
convert modules that use VERBOSE-YES/NO (uppercase) env variable
to do things differently at compile time
Convert canvas to use SAL_INFO/SAL_WARN mechanism instead of its
home-grown 'verbose logging'.
Change-Id: I2898d2309d421457839e3cd7078166c6da919882
Reviewed-on: https://gerrit.libreoffice.org/17619
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
We used it all over the place without leading :: already anyway, even
in many files in include. So let's be consistent. In the majority of
cases, prefer the easier-on-the-eyes choice, not the "safe" one.
In those files in include where *all* existing uses of ::vcl:: indeed
used the :: prefix, there let's keep it for consistency.
Change-Id: If99cb41d3bf290d38c601d91125c3c8d935e61d0
The only thing that needs to be reimplemented is the pbuffer based
custom sprite rendering. We should use a FBO with a texture backend
for that. This will also save several OpenGL context switches!
Change-Id: I4aef33ae2499e44c8b5f41c296d8721cb94a37a1
It appears that the C++ standard allows overriding destructors to be marked
"override," but at least some MSVC versions complain about it, so at least make
sure such destructors are explicitly marked "virtual."
Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
Adds opengl canvas implementation - display-list-based, all
rendering done as textured geometry. Needs shader support.
Currently compiles and works on Linux, Mac should be ~easy to
add, win32 eventually.
Change-Id: Ibf3eb88d6a36a91b2960a3a6320d708160e4fc14
