Hi all,
so gbuild migration is almost finished, so we might need some new task for the
heroes doing all the migration work there. Going for ideas, I found the old
discussion at:
http://nabble.documentfoundation.org/Re-shiny-uno-version-Desktop-IDL-td3989884i20.html#a3995285
about callbacks/slots and signals. But while I (as likely everyone else) think
tools DECL_LINK is ugly and needs to die some day, I dont find an urgent need
to move away from it(*).
OTOH, we still have two competing "dispatch" implementations, having
essentially the same intend and propose:
- SfxDispatcher in sfx2/source/control/dispatch.cxx
- framework::DispatchProvider in framework/source/dispatch/dispatchprovider.cxx
I dont want to argue about which one is 'better' -- but this duplication is
blocking further refactorings and cleanup there and elsewhere.
Applying the attached crude patch and running
make -skj32 2>&1|grep class\ SfxDispatcher|cut -f1 -d/ |sort|uniq -c|sort -n
finds:
1 avmedia
3 vbahelper
8 starmath
14 cui
29 basctl
60 svx
87 sc
158 sd
103 sw
so at least outside of svx,sc,sd,sw it should be possible to kill that code of.
Churning through those four modules might be more tricky, but given that:
- there are SID_* items used for the dispatch
- they are created with the horrible svidl tools from idl/
- those create fragile and hardcoded integer ids
- these are hardcoded in way too many places in our codebase, e.g.
- http://opengrok.libreoffice.org/xref/core/framework/source/uielement/menubarmanager.cxx#159
- http://opengrok.libreoffice.org/xref/core/sd/source/ui/slideshow/slideshowimpl.cxx#2185
In the long term, getting rid of the 'slot:12345' dispatches would be a very
Good Thing(tm) -- once the SfxDispatcher is dead, one can move about to make
framework::DispatchProvider sane.
Opinions?
Best,
Bjoern
(*) Which probably could be done easily by replacing the DECL_LINK
implementation with one based on e.g. boost::signals2 and then slowly replacing
the tools macros with a direct boost call. But when that is done _all_
signal-like implementations should be moved to the one we settle on too:
- DECL_LINK from tools/inc/tools/link.hxx
- SfxBroadcaster from svl/source/notify/brdcst.cxx
- SwClient from sw/inc/calbck.hxx
- probably at least some five more that I am not immediately aware of ;) ...
diff --git a/sfx2/inc/sfx2/dispatch.hxx b/sfx2/inc/sfx2/dispatch.hxx
index 59e87fa..c68aefa 100644
--- a/sfx2/inc/sfx2/dispatch.hxx
+++ b/sfx2/inc/sfx2/dispatch.hxx
@@ -123,6 +123,7 @@ public:
virtual void SetExecuteMode( sal_uInt16 );
+#ifdef SFX2_DLLIMPLEMENTATION
const SfxPoolItem* Execute( sal_uInt16 nSlot,
SfxCallMode nCall = SFX_CALLMODE_SLOT,
const SfxPoolItem **pArgs = 0,
@@ -147,6 +148,32 @@ public:
SfxCallMode nCall,
sal_uInt16 nModi,
const SfxItemSet &rArgs );
+#else
+ const SfxPoolItem* deprecated_Execute( sal_uInt16 nSlot,
+ SfxCallMode nCall = SFX_CALLMODE_SLOT,
+ const SfxPoolItem **pArgs = 0,
+ sal_uInt16 nModi = 0,
+ const SfxPoolItem **pInternalArgs = 0);
+
+ const SfxPoolItem* deprecated_Execute( sal_uInt16 nSlot,
+ SfxCallMode nCall,
+ SfxItemSet* pArgs,
+ SfxItemSet* pInternalArgs,
+ sal_uInt16 nModi = 0);
+
+ const SfxPoolItem* deprecated_Execute( sal_uInt16 nSlot,
+ SfxCallMode nCall,
+ const SfxPoolItem *pArg1, ... );
+
+ const SfxPoolItem* deprecated_Execute( sal_uInt16 nSlot,
+ SfxCallMode nCall,
+ const SfxItemSet &rArgs );
+
+ const SfxPoolItem* deprecated_Execute( sal_uInt16 nSlot,
+ SfxCallMode nCall,
+ sal_uInt16 nModi,
+ const SfxItemSet &rArgs );
+#endif
const SfxSlot* GetSlot( const String& rCommand );
Context
- Thoughts on killing off SfxDispatcher::Execute(..) · Bjoern Michaelsen
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.