Inspired by a recent bug report where we were assigning the result
of VclPtr<T>::Create to a raw pointer.
As a consequence, we also need to change various methods that were
returning newly created Window subclasses via raw pointer, to
instead return those via VclPtr
Change-Id: I8118e0195a5b2b4780e646cfb0e151692e54ae2b
Reviewed-on: https://gerrit.libreoffice.org/31318
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
see gnome#768128 for extra details
under wayland, given the misery here I'm going to just disable toggling between
docked and undocked under wayland, and throw away user config on toggling
docked/undocked away from the defaults. You can still drag docked things around
to new docking position, but you can't pull them out of the dock to float.
non-wayland is unaffected
Change-Id: Iaa859f3420e6d1b103a8b93d1ad8f82dbffe75d4
Reviewed-on: https://gerrit.libreoffice.org/30752
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Look for places where we are accidentally assigning a returned-by-value
VclPtr<T> to a T*, which generally ends up in a use-after-free.
Change-Id: I4f361eaca88820cdb7aa3b8340212db61580fdd9
Reviewed-on: https://gerrit.libreoffice.org/30749
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(I'm not sure about how good are the changes from ScopedVclPtr
to non-scoped, and disposeAndClear to clear. They aren't really
needed, because of the VclReferenceBase::mbDisposed logic. But
at least they should be safe, as long as we have disposeOnce
calls in Menu's dtor.)
See also previous commits:
4433d95b374c13a3501cdf3a6e273f68eb49873a
("MenuItemData now properly disposes the submenu")
89c23b4aaef931b5d6009efaf44ce6e6c976e8d4
("Sub menus no longer need manual disposing")
Change-Id: I9d455a94590f5eec9b097947f6984f1b3e477b52
...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
some places are marked with "dodgy"- need to check those to see
what is going on, because they are leaving dangling pointers behind
in the Menu class
Change-Id: I41d5c7c0fec2f70ce9e3ffdc48cd03d26c0a869b
Reviewed-on: https://gerrit.libreoffice.org/26516
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
probably not much performance benefit, but it sure is good at
identifying leftover intermediate variables from previous
refactorings.
Change-Id: I3ce16fe496ac2733c1cb0a35f74c0fc9193cc657
Reviewed-on: https://gerrit.libreoffice.org/24026
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
... in modules editeng to oox.
Replace with C++11 delete copy-constructur and
copy-assignment.
Remove boost/noncopyable.hpp includes and
one unused boost/checked_delete.hpp include in linguistic.
Change-Id: I5a38d8e5ac1b4286bdeb3858d56490a53d13fe80
Reviewed-on: https://gerrit.libreoffice.org/23928
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
This is just too hard, it would all be much easier if the ActionGroup existed
right from the start of the entire process. So smuggle in to the ctor the
toplevel frame that the menubar will be inserted into so we can use its
ActionGroup from the start.
That would suggest that we could then just keep the hierarchy in sync as it is
created rather than finding opportune moments to update /generate it.
Change-Id: I550f94a994210423ab9cea1986e643056cb5bd29
Reviewed-on: https://gerrit.libreoffice.org/23287
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
when using native gtk3 menubars.
The issue is that MenuBarManager does not own its MenuBar.
And in this embedded menubar situation a new menubar is newed and passed to
m_pInplaceMenuBar but nothing destroys it.
Now with native gtk3 menubars this becomes obvious as the native menubar stays
behind, while in the non-native case the old menubar is replaced by
the new one so while it still leaks the menubar you don't see it.
Change-Id: Id732cb66664a71efc471d7bad35f4de890e1017e
Will use a different approach for NotebookBar.
Also this should not be in 5.1.
This reverts commit 8c1014021dbe9da2e18233d215b970f5359db67b.
Change-Id: Ic699723818a890bf4c3be3a2c045527148bd118b
Reviewed-on: https://gerrit.libreoffice.org/20075
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
It just includes a bunch of other boost headers; mostly we need
boost/noncopyable.hpp so include that directly.
This eliminates 831 MB(!) of boost/preprocessor/seq/fold_left.hpp
completely, which is the 2nd biggest header after ustring.hxx.
Change-Id: I3df55770adcb46e56f389af828e8ba80da2dc1f2
At least OutputDevice::acquire/release use a plain unguarded int and ++, --, so
apparently rely on the SolarMutex being locked whenever they are called. Fixed
those places that caused "make check" to fail for me when temporarily adding
DBG_TESTSOLARMUTEX() to OutputDevice::acquire/release. (A recurring pattern is
that a class fails to ensure the SolarMutex is locked around the destruction of
non-null VclPtr members.)
Change-Id: I77cba6f3908f2de1b516ce28f1c3c43b3f57a9c5
Turn the Link class into a template abstracting over the link's argument and
return types, but provide default template arguments that keep the generic,
unsafe "void* in, sal_IntPtr out" behvior. That way, individual uses of the
Link class can be updated over time.
All the related macros are duplicated with ..._TYPED counterparts, that
additionally take the RetType (except for LINK_TYPED, which manages to infer the
relevant types from the supplied Member).
(It would have been attractive to change the "untyped" LinkStubs from taking a
void* to a properly typed ArgType parameter, too, but that would cause
-fsanitize=function to flag uses of "untyped" Link::Call.)
Change-Id: I3b0140378bad99abbf240140ebb4a46a05d2d2f8
