Compiler plugin to replace with matching number(), boolean() or OUString ctor,
ran it, few manual tweaks, mark as really deprecated.
Change-Id: I4a79bdbcf4c460d21e73b635d2bd3725c22876b2
...which incompatibly changed Addons.xcs and breaks extensions (and LibreLogo,
which adds to Addons.xcu even though it is not an extension). See the mail
thread starting at
<http://lists.freedesktop.org/archives/libreoffice/2013-July/054612.html>
"[Libreoffice-commits] core.git: #i121577# Allow setting toolbar name in
Addons.xcu" for details.
This reverts commit 85f072ef33ef47b5e3e0bcd51acb5c4179cde2c2
"Resolves: #i121577# Allow setting toolbar name in Addons.xcu" plus follow-up
af572d9fbb744c9691abe465815d7927a9d11510 "Related: #i121577# Allow setting
toolbar name in Addons.xcu," f13f9b5cc5267a7a5606b1a89db91b6d7aef5f9c "various
.xcus are gone now," and 37d9921797a3ad3be8257fbfee11326549fcd987
"odk/examples/python/toolpanel/CalcWindowState.xcu is still in use," plus those
parts of f97ca6f65182efc6542c53ac5e973b3ff398a5d1 "Resolves: #i116455# Make
toolbar style settings persistent" that apparently belong to the fix for
i#121577 rather than i#116455.
Change-Id: Ib744566f3d8da7d9008d7dad8bec60f1bf32e743
This internal API has always been problematic because we cannot
support it under the Linux toolkits, where it has in fact always
just returned the size of the screen.
Change-Id: I406bcbca8a4161b4261ef46940823bb07c6ad18b
Reviewed-on: https://gerrit.libreoffice.org/4976
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@suse.com>
Tested-by: Michael Meeks <michael.meeks@suse.com>
- "ModuleName" --> "ModuleIdentifier": the IDL definition for
css::frame::PopupMenuControllerFactory and
css::frame::StatusbarControllerFactory tells to use a property named
"ModuleIdentifier", but in the code it is named "ModuleName"
- Undocumented css::frame::ToolbarControllerFactory
- Fix service name of ToolbarControllerFactory (ToolbarControllerFactory
instead of ToolBarControllerFactory)
- Convert the three service factories to new style, and use these
new-style services in the source code
- Implement multiple inheritance: added new css::frame::XUIControllerFactory
- Added a (true) base class and implemented the three factories in a
single file
(cherry picked from commit acc7fed28f54f836b0923180431a0c180f91e98c)
Conflicts:
framework/inc/pch/precompiled_framework.hxx
framework/inc/uielement/toolbarmanager.hxx
framework/inc/uifactory/popupmenucontrollerfactory.hxx
framework/inc/uifactory/statusbarcontrollerfactory.hxx
framework/inc/uifactory/uicontrollerfactory.hxx
framework/source/uielement/addonstoolbarmanager.cxx
framework/source/uielement/menubarmanager.cxx
framework/source/uielement/popupmenucontroller.cxx
framework/source/uielement/statusbarmanager.cxx
framework/source/uielement/toolbarmanager.cxx
framework/source/uifactory/popupmenucontrollerfactory.cxx
framework/source/uifactory/statusbarcontrollerfactory.cxx
framework/source/uifactory/uicontrollerfactory.cxx
framework/source/unotypes/fwk.xml
offapi/com/sun/star/frame/PopupMenuControllerFactory.idl
offapi/com/sun/star/frame/StatusbarControllerFactory.idl
offapi/com/sun/star/frame/makefile.mk
svtools/source/uno/toolboxcontroller.cxx
Change-Id: Ia8580539badf650a84bc6e57a6b832071e011f0a
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
The LayoutManager for some reason has both a ToolbarLayoutManager
pointer field, and a uno::Reference to an aspect (or whatever term one
should use) of the same ToolbarLayoutManager. (I.e. esssentially two
fields for the same thing. Why it doesn't create such variables where
needed instead I don't know.)
Anyway, for some reason there were lots of instances where a local
variable was initialised with this second field but then never used. I
removed those. (Surely just copying the field into a local variable
doesn't have any interesting side effect that would explain this
pattern?)
Change-Id: Ibdfbd9476c39d3e83b58e81469b94d9a87444ca8
This service was never documented in an IDL file.
All it did was provide a wrapper around some VCL module API.
Now that we can link the VCL stuff into SD and SDEXT, just
access the API directly.
Change-Id: Ic0ba34c2bca797baa7319878d98cfe3a4ec59d4d
...in favor of existing new-style configuration::theDefaultProvider singleton.
Theoretically, ConfigurationProvider instances can be created with specific
Locale and EnableAsync arguments, but this is hardly used in practice, and thus
effectively all uses of the ConfigurationProvider service use the
theDefaultProvider instance, anyway.
theDefaultProvider is restricted to the XMultiServiceFactory interface, while
ConfigurationProvider also makes available XComponent. However, dispose must
not be called manually on theDefaultProvider singleton anyway, and calls to
add-/removeEventListener are so few (and in dubious code that should better be
cleaned up) that requiring an explicit queryInterface does not really hurt
there.
This commit originated as a patch by Noel Grandin to "Adapt
configuration::ConfigurationProvider UNO service to new style [by creating] a
merged XConfigurationProvider interface for this service to implement." It was
then modified by Stephan Bergmann by deprecating ConfigurationProvider instead
of adding XConfigurationProvider and by replacing calls to
ConfigurationProvider::create with calls to theDefaultProvider::get.
Change-Id: I9c16700afe0faff1ef6f20338a66bd7a9af990bd
Create a merged XToolkit2 interface for this service to implement.
Which is backwards-compatible, but does not require creating a new service.
Also mark sub-interfaces as non-optional.
Change-Id: I278d0288e92be277033013302267cf93f7d70480
