Thoughts on killing off SfxDispatcher::Execute(..)

[Bjoern Michaelsen]

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>