071e23fee0 "add move operators for VclPtr" added
(among other things) a move assignment operator that rather copied m_rInnerRef.
But if b72c6feba8 "manage VCL widgets using
rtl::Reference" had not pointlessly introduced a user-declared copy constructor
in the first place, all the copy/move special member functions would be
implicitly declared (as VclPtr does not have a user-declared destructor).
Change-Id: I1bec05a7a1b5b48a7b7d74e64a88f118454f8cb2
There does not seem to be any need for that atom thing as we are
perfectly happy using plain OUStrings in the same struct, not to mention
that font names are supposed to be unique so I don’t see what we are
saving here.
As this was the only use for unotools/atom, it goes with it.
Change-Id: If9d58d84fff0403f9b2c41fe594b99028b30c2f4
Reviewed-on: https://gerrit.libreoffice.org/31520
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
...when merely toggling the edit mode of a Calc document embedded in another
document (via "Insert - Object - OLE Object... - LibreOffice 5.4 Spreadsheet").
Interestingly, none of the other document kinds seem to have this problem.
(Maybe it's even unhelpful that ScTabViewShell::InnerResizePixel calls
SetDocumentModified() at all?) Anyway, pass this inplaceEditModeChange
information down there.
Change-Id: Iffb24b068419e3608c9f4b5e9645e44e1716aafe
These flags mean nothing these days, there are either always true or
always false, since we no longer support bitmap or Type 1 fonts.
Change-Id: Ie14ca480225a6346d868a44e58e7666c3a06931d
Reviewed-on: https://gerrit.libreoffice.org/31346
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
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>
Since the entries and their order are part of the
public API, and will not change, numbering them
makes it easier to trap particular callbacks by
their number (as that's what shows in logs and
the debugger).
Change-Id: Ife2fe3e601ce3dce0939363d748fcb54d3c85fd4
Reviewed-on: https://gerrit.libreoffice.org/31257
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
There is annoying overloading between Window::Notify and
SfxListener::Notify, and the Window one has apparently fewer
implementations, so rename that and remove lots of disambiguating
"using Notify" in multiply inheriting classes.
Change-Id: I8b597fd9e70cf2e7103b9dfa7cc666e79e7aff49
this is exposed through uno however, so move it into VCLXMenu to continue to
support it doing nothing of great value there
Change-Id: I6888e61cbec85faa2d1fcca8731ab42023e594c6
Deallocate the XTransferable object async using AsyncCallback
(that uses Application::PostUserEvent) which executes the
callback in a thread-safe way on the main thread. This avoids
a deadlock at deallocation so that the XTransferable.
Modify AsyncCallback to not hold the SolarMutexGuard because
Application::PostUserEvent is considered thread-safe.
Document Application::PostUserEvent thread-safety
Change-Id: I4237a1cf380e8be66b3eefc393a58bb4853bf4e1
Reviewed-on: https://gerrit.libreoffice.org/31126
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
This is the final fix for tdf#41542 - enabling the UI to adjust the
padding without requiring an enabled border line.
Because almost every document edited by LO5.3 will gain the setting
ALLOW_PADDING_WITHOUT_BORDERS = false, it cannot be kept as a
preventative compatibility setting. Otherwise any document edited
in 5.3 would act differently from any other document - not being
allowed to modify borderless padding for frames, even in 5.4+.
That would be a very confusing corner-case that is best avoided,
so removing all compatibility code (which currently has no use).
So, if an AllowPaddingWithoutBorders=false compatibility
situation is ever required in the future, do not
resurrect the name ALLOW_PADDING_WITHOUT_BORDRES. Additionally, code
will also be needed to send the compatibility setting for
each type of border (page, paragraph, character, header, frames, image).
See commit f013d4a1f4 as an example
of how to implement that for frames.
This commit means there is a lot of dead code now (m_bBorderDist and
mbAllowPaddingWithoutBorders are always true). LO5.7 seems like a good
target to clean that up - to allow time to easily fix any regressions.
Change-Id: I2d2091fa34f8b178a59347b35a81c944c9b24ed7
Reviewed-on: https://gerrit.libreoffice.org/31105
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
