at least calc deals with paste-special correct, if other applications don't
let's fix 'em up one by one
Change-Id: I1beb04e227f2971ee8ef2ce9b7ebdabf566be086
calc application specifically handles PasteSpecial so no need to set the state of the menu entry to enabled always ( for calc at least )
Change-Id: Iaf13dd825f0cbdcf9f455db07d727753fae90868
Now that 5c47e5f63a79a9e72ec4a100786b1bbf65137ed4 "fdo#51252 Disable copying
share/prereg/bundled to avoid startup crashes" removed the use of share/prereg,
there is no longer need to generate it in the first place (by calling "unopkg
sync" at build or installation time), and so no need for the "unopkg sync" sub-
command, either. This also allows to simplify some of the jvmfwk code that was
only there so that "unopkg sync" (which can require a JVM) can work in "hostile"
environments (during build and installation).
Change-Id: I52657384f4561bf27948ba4f0f88f4498e90987f
Part of MultiLineEdit was moved down from stvools to vcl
with name VCLMultiLineEdit. MessBox uses it to display the
message in read-only mode. Some of svtools' classes - which
are necessary to implement VCLMultiLineEdit - were moved to
vcl as a whole, and their includes are rewrite.
Note: ExtTextView and ExtTextEngine classes would be leaved in svtools
if VCLMultiLineEdit is a template class, but two macros: IMPL_LINK
end IMPL_LINK_NOARG make it impossible to use template syntax.
Change-Id: I26543868d8081c225c7125404d23369de3c3afcd
This reverts commit b21661ce4200fd8040a213770a3f9e63a4b9f137.
this breaks with ../framework/source/lomenubar/MenuItemInfo.hxx:49:12: error: expected ‘;’ at end of member declaration
This reverts commit 5b2cb23c429e1be1099008473770c634ce96c969.
That did not fix the bug (fdo#47021), but apparently it does cause
problems, such as the failure of the sfx2 DocumentEvents test (that
doesn't crash any more since 228a3f8b9f279e80917968d9780e822a1d684ada);
without the SolarMutexReleaser the test doesn't fail for me.
...this can apparently happen during the complex.sfx2.DocumentEvetns JUnit test
(which would otherwise sometimes fail with an uncaught RuntimeException).
Change-Id: I4c96a3bc6bf08e92ec3ec82d76812a35226494fb
don't count the calls, but maintain a simple flag.
Consequently, let sw's UndoManager simply delegate now, and
change the UndoManagerHelper to maintain a lock counter itself.
Conflicts:
framework/source/fwe/helper/undomanagerhelper.cxx
avoid where possible (by checking beforehand), and assert when caught
Conflicts:
framework/source/fwe/classes/framelistanalyzer.cxx
framework/source/helper/titlebarupdate.cxx
framework/source/services/frame.cxx
framework/source/uifactory/windowcontentfactorymanager.cxx
sfx2/source/notify/eventsupplier.cxx
The Lanczos scaling is of very good quality, but it's rather slow,
which can be very noticeable with large images, so it's not a very
good default for everything. And in general, it's not good to refer
to a specific algorithm when all one usually wants is fast/default/best.
Some of these changes are a bit of a guess between default/best,
but the general logic is that best should be used only for images
that won't be large or where the possible waiting does not matter.
Change-Id: I53765507ecb7ed167890f6dd05e73fe53ffd0231
