Issue 122024 - [sidebar] Dispatch interception is broken
Summary: [sidebar] Dispatch interception is broken
Status: CONFIRMED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: 4.0.0-dev
Hardware: All All
: P3 Normal (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks: SidebarEnhancement sidebar400-dev
  Show dependency tree
 
Reported: 2013-04-09 22:58 UTC by Ariel Constenla-Haile
Modified: 2020-03-04 08:45 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Zip file with a Dispatch Provider Interceptor example component (32.47 KB, multipart/x-zip)
2013-04-09 22:58 UTC, Ariel Constenla-Haile
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Ariel Constenla-Haile 2013-04-09 22:58:55 UTC
Created attachment 80516 [details]
Zip file with a Dispatch Provider Interceptor example component

Dispatch interception, as explained here http://wiki.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/Dispatch_Interception, is broken.

Download the zip with the example, and unzip it on the sdk/examples/cpp folder
Set up the SDK environment, cd openoffice/basis4.0/sdk/examples/cpp/DispatchInterceptor/src and compile the example with DEBUG=yes to turn OSL_TRACE on:

make DEBUG=yes

then run the example:

make DEBUG=yes DispatchInterceptorDemo.run

The example has a Job to register the interceptor on Writer/Impress/Draw. This can be controlled by adding more modules in StaticSupportedModules::operator(), on Job.cxx

The example will intercept the commands indicated in StaticInterceptedURLs::operator(), on DispatchInterceptor.cxx

The interceptor does nothing, it works just like a proxy, dispatching intercepted commands at the original dispatch object, and notifying status updates.

---------------

To reproduce the bug:

- make DEBUG=yes DispatchInterceptorDemo.run
- new Writer document
- dt + F3 to insert dummy text
- select a word, and Ctr+B to set it in bold

The command .uno:Bold should be intercepted, and thus dispatched through the interceptor:

Trace 12373/1: "dispint::DispatchInterceptor::dispatch - ".uno:Bold""
Trace 12373/1: "dispint::DispatchInterceptor::statusChanged - ".uno:Bold""

The status update is reflected in the formatting toolbar item, but not in the sidebar: the bold toolbox item is not checked.

- Press Bold in the sidebar while the cursor is in the bold word: the word is still bold (it should have been toggled). The sidebar bold item is now checked.

- Press Bold in the sidebar once again: the sidebar removes the bold from the word, but bypasses the interceptor: the interceptor didn't dispatch .uno:Bold
Comment 1 Andre 2013-05-15 08:43:57 UTC
This is probably another example of the sidebar panels not using the standard toolbar controllers.  But it is also caused by a gap of functionality between slots and commands: Most sidebar panels use the usual SFX2 slot mechanism to make (asynchronous) function calls, like most of the rest of AOO.  For some reason the dispatch interception of UNO commands has not been ported to slots.

There are three ways to fix this

1 Modify all relevant panels to explicitly support dispatch interception.  Maybe this could be handled by extending the sidebar ControllerItem.

2 Convert the sidebar controls to use toolbar controllers instead of spelling everything out explicitly.

3 Integrate dispatch interception into slot handling.


I think that 3 would be the best and most elegant solution but would likely introduce subtle regressions that would be hard to find.  We should do 2 anyway when time premits (after the 4.0 release).  Option 1 would basically be a waste of time but seems to be the only practical way to fix at least the text property panel for a 4.0 release.
Comment 2 Andre 2013-05-15 08:57:16 UTC
I just looked at the Dispatch_Interception description that was referenced in comment 1.  It is even more bizarre than I thought it was.  Explicit modeling of the dispatch/interceptor chain.  Incompatible concept of chaining/interception when compared to slot handling.  And yet one is mapped to to the other when a slot of command is executed/dispatched to give the illusion that both concepts are equivalent.

Anyway, option 1 will certainly not work for slot calls.  Option 2 seems to be the best way to go.  But not for 4.0.

Does anyone have a better idea?
Comment 3 Andre 2013-05-16 11:56:15 UTC
Please see comment 19 in bug 121960 (https://issues.apache.org/ooo/show_bug.cgi?id=121960#c19) for the reason why I remove this issue from the list of blockers of bug 121420.