Thoughts on killing off SfxDispatcher::Execute(..)
Bjoern Michaelsen
bjoern.michaelsen at canonical.com
Sun Feb 24 06:24:06 PST 2013
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 ;) ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: obsolete-SfxDispatcher.diff
Type: text/x-diff
Size: 1962 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20130224/e5846c3a/attachment.diff>
More information about the LibreOffice
mailing list