* UUIInteractionHandler still needs to implement XInitialization.
* Moved ambiguating InteractionHandler typedef out of the way.
* Removed InteractionHandler.createDefault, as it was originally stated that "it
is strongly recommended that [the "Parent"] property is supplied."
* Added back documentation about Parent and Context.
* Simplified some call-sites to directly use XInteractionHandler2.
Change-Id: I1029b8f3cf079171c75920cafaaa44b5bbada883
Since we don't need to expose XInitialisation, we can make the new-style
service implement XInteractionHandler2.
Change-Id: Ib27beed1c12df17592c6472d6f58c233d2c41558
Create a merged XGlobalEventBroadcaster interface for this service to implement.
Which is backwards-compatible, but does not require creating a new service.
Also add two interfaces to the IDL, which the service already implemented,
and existing client code already used.
Change-Id: Ib7a9a30c0e50146ef621f3fe5227f8aad3190516
* 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
Now if we make e.g. the stack window floating, then the watch window
will occupy the whole width of the line (and vice versa, also for the
Dialog Editor with object catalog and property browser). If we put it
back again, than we get back the previous state of the strip.
Change-Id: I634614ff2e9d5f790ad759656a79a38d49c4afc4
Lots of raw pointers have been converted to boost::scoped_ptr to reduce
the number of 'delete's and the possibility of memory leaks.
Some pointers have been converted to references, to reduce the needless
checking for nullptrs, and so simplifying the code.
Also some #define-s have been converted to C++ constants or enumerations.
Change-Id: Ifbeb78f744bac7a96c8a446ff4db90dedf85fe26
This fixes the crash of 'Basic IDE: Docking property browser under
object catalog' commit. The aPropertyBrowser data member was replaced by
a new-allocated pointer. We need this because toolkit releases it by
delete.
When the property browser is closed in the floating state, it tells
DialogWindowLayout to null the pointer. If the user clicks the 'property
browser' button on the toolbar, it is created again.
Change-Id: Ie842a72fe37dfdd2ed5921ffa2f1f41d3f2c51c6
Reviewed-on: https://gerrit.libreoffice.org/568
Tested-by: Noel Power <noel.power@suse.com>
Reviewed-by: Noel Power <noel.power@suse.com>
Now the property browser can be docked in the same way as all other
dialogs in the Basic IDE and the Dialog Editor.
The property browser (PropBrw, for which PropertyBrowser would be a
better and easier-to-remember name IMO) is derived from
basctl::DockingWindow instead of SfxDockingWindow. PropBrwMgr was
removed (it seemed to be only a wrapper), and PropBrw is now a data
member of DialogWindowLayout (aPropertyBrowser).
Change-Id: I06737a5cbc985888432630714cb919d1bbbcbb49
Reviewed-on: https://gerrit.libreoffice.org/518
Reviewed-by: Noel Power <noel.power@suse.com>
Tested-by: Noel Power <noel.power@suse.com>
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
Create a merged XPipe interface for this service to implement.
Which is backwards-compatible, but does not require creating a new service.
Change-Id: I682633c6252aab503eb2469c9bd2ba771f10bc4b
In Basic IDE in Object Catalog, only methods could be loaded by
double-click. Now modules and dialogs can be too.
Change-Id: If1c4412d2f6d35e6d1cbf48e700e2566dad9e97a
Reviewed-on: https://gerrit.libreoffice.org/515
Reviewed-by: Andras Timar <atimar@suse.com>
Tested-by: Andras Timar <atimar@suse.com>
This solves an issue about Edit > Redo in BasicIDE (Hungarian site):
http://bug.openscope.org/browse/OOO-269
1. Redo should have a shortcut (Ctrl+Y), like in other parts of
LibreOffice. (Undo has the usual Ctrl+Z.)
2. In the Edit menu, Undo and Redo should print something after the
colon (what is to be undone, redone).
This patch fixes both.
Unfortunately the shortcut isn't shown in the menu (it's in
vcl/source/window/keycod.cxx like Undo, and not in
officecfg/registry/data/org/openoffice/Office/Accelerators.xcu).
Change-Id: I2cfbfeb7d57309a27676e48943633cdb194288bc
Reviewed-on: https://gerrit.libreoffice.org/514
Reviewed-by: Andras Timar <atimar@suse.com>
Tested-by: Andras Timar <atimar@suse.com>
Now all names in basctl are in namespace 'basctl'.
There were lots of names that included the word 'Basic' or 'BasicIDE' in
it, e.g. BasicIDEData, BasicDocumentEntry, BasicTreeListBox,
BasicIDEModule, IDEBaseWindow etc. This information is now stored in the
namespace name, so the names could be shortened: basctl::DocumentEntry,
basctl::TreeListBox, basctl::Module, basctl::BaseWindow etc.
Some other minor changes:
* LibInfos, LibInfoItem, LibInfoKey ->
LibInfos, LibInfos::Item, LibInfos::Key
* The header guards are now uniformly BASCTL_FILENAME_HXX, instead of
e.g. _FILENAME_HXX, which is undefined behaviour because of the '_'.
* namespace BasicIDE, BasicIDEGlobals, basicide -> namespace basctl
* BASICIDE_TYPE_MODULE, ... -> basctl::TYPE_MODULE, ...
Change-Id: I2a9b493562d0d8a2510d569798fbe9e1161b7c9b
Reviewed-on: https://gerrit.libreoffice.org/501
Reviewed-by: Andras Timar <atimar@suse.com>
Tested-by: Andras Timar <atimar@suse.com>
a) got rid of defaulted params in virtual base class methods
b) made some no-op virtual methods in the base class pure thus making the base
class abstract
c) made LayoutManager no longer inherit utl::ConfigurationListener as it wasn't
actually listening or acting on any configuration changes
Change-Id: Iab1783f6b5a35b130287a2aedbd1dc8413793182
The color setting was picked from SplitWindow::Paint()
for visual consistency with the sizers used in Impress
for example.
This commit also resurects presumably dead code.
In fact GDB let me see that only the short path
was taken.
This has an impact on Calc's window splitters and
on more visibly on the basic IDE which now looks
much nicer :)
EDITS:
restricted this commit impact to IDE as a poc
Change-Id: I9a051fd894feccff4bbc7db7efe1160cb2c3a2c6
very basic support for this, basicially you can dock the browser anywhere now
hence lots of behaviour niggles remain, e.g
1) it probably doesn't make sense to be able to dock the browser into top or bottom quadrants ( we need to implement the Docking ( maybe PrepareToggleFloating mode ) method(s) in PropBrw ( propbrw.cxx )
2) open floating or not ( if propertybrowswer is open )
3) should we leave the 'properties' context menu when selecting shapes in place or not
4) switching between Module and Dialog tabs, we probably should 'remember' docked position and state
Change-Id: Ibea4be3397eeac613642934662c3a9868fdf783b
