The xml.sax.Parser service already existed, it just did not have
a new-style service to create it.
Change-Id: I6f145a7504ff9e149c802f723991954a2801cbc9
Lets rename the multiargument SetPosSizePixel to
setPosSizePixel drop the various using Window::SetPosSizePixel
and work towards de-virtualizing SetPosSizePixel/SetPosPixel and
SetSizePixel and doing the work in a virtual setPosSizePixel
Change-Id: I7057654168001b67becee1791e97f9e9dc01f7b8
* As UCB is only ever initialized with "Local"/"Office", remove this
configuration vector completely. The "create" ctor creates an instance
internally initialized with those "Local"/"Office" keys. Special (test) code
can still instantiate an uninitialized one via plain createInstance. And for
backwards compatilibity process startup still ensures to create an initialized
instance early, in case there is still code out there (in extensions) that
later calls plain createInstance and expects to get the already-initialized
(single) instance.
* XInitialization is an "implementation detail" of the UniversalContentBroker
service, do not expose in XUniversalContentBroker.
* ucbhelper/configurationkeys.hxx is no longer needed and is removed.
* ucbhelper/contentbroker.hxx is an empty wrapper and is removed; however, that
requires ucbhelper::Content constructors to take explicit XComponentContext
arguments now.
* The only remaining code in ucbhelper/source/client/contentbroker.cxx is
Android-only InitUCBHelper. Is that relevant still?
Change-Id: I3f7bddd0456bffbcd13590c66d9011915c760f28
It introduces the 'FilterProvider' property in the media descriptor
to optionally bypass the normal loading process and let the external
filter provider to handle the loading.
For now I'm overwriting the csv import filter just to see how this
could work just as an experiment.
Orcus still needs a lot of work, and it crashes very often at the
moment.
Change-Id: I11b34572c71073144804a7d0dd5176c8067d8deb
The service implementation used "com.sun.star.frame.UICommandDescription"
since forever, so the IDL file was essentially wrong documentation.
But since 7a464263cc5c2ca2b7128734ff4860e02d662818 converted the service
to new-style, it cannot be instantated any more and e.g. clicking on
Tools->Customize crashes.
(Adapting the implementation instead would be an incompatible change.)
Change-Id: I564bddaf3836827f5b72360a2bde19d6158b7ba5
Create a merged XModuleManager2 interface for this service to implement.
Which is backwards-compatible, but does not require creating a new service.
Explicitly document the XNameReplace interface in the IDL, which
is already implemented by the service, since there is code currently using it.
Change-Id: Ib46349174b1ce495c240031e93c9427fc33d9853
...to better be able to change its set of implemented interfaces later on.
Some potential for further clean up:
* a generic helper for supportsService;
* remove need for impl_createFactory;
* base impl_createInstance on XComponentContext instead of XMultiServiceFactory;
* replace ThreadHelpBase with a plain osl::Mutex.
Change-Id: Ia2cbd14872a609c2ed57d9ce58b546f087c2fdfb
...it apparently leads to crashes, but is probably not good from a usability
perspective anyway (as the menu closes again when the dialog appears/is operated
on by the user).
For now, just disable the Java specific interaction handler here; might make
sense to address this more generally though (there's framework::QuietInteraction
btw).
Change-Id: I6ae303c0084549b5339d219e158cdb89e5a6b331
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
