The configuration settings found in /core/svx/sdi/svx.sdi have the boolean settings AccelConfig, MenuConfig, and ToolBoxConfig to determine whether each uno command appears in the keyboard tab, menu tab, or toolbar tab of the customization dialog, but unfortunately this isnt functioning correctly.
For example, .uno:BezierDelete with the label 'Delete Points' found in the drawing category is set to only be added to a toolbar, but unfortunately it appears in the menu and keyboard tabs. Another example is .uno:InsertDraw ( 'Draw Functions' in Drawing category ), which is set to not appear in the keyboard tab, but it does.
Indeed, it doesn't work that way for many years. Currently the protocol between the core application and the customization dialog is the css::frame::XDispatchInformationProvider UNO interface, which allows filtering only by a command group . The current implementation on the application side is that if one of those *Config booleans is true, the command will be returned via XDispatchInformationProvider , and therefore on the customization dialog side it will be visible in all tabs.
So what we probably need here is to introduce a new optional interface which (when supported by the currently active application) will allow asking the application for a specific kind of commands, based on the current customization tab.
It's a core function, admittedly not critical but still relevant. So I'd treat this as a major bug with high importance.
By working on a patch for this I am gaining some understanding of idl. Here is a patch for review.
The patch works as expected not evaluating the code. When I type "Table Cell" the background color is listed only under Toolbars. But that's hard to understand for the user since we define whether a command can be used at a certain position. Maybe it would be easier to handle when the entry is grayed out (as well as the Add button). But OTOH it sounds like a lot of work for maybe not so much reason. What do you think?
(Adding Muhammet as he did a lot work around this)
Heiko, I was excited about this patch but have been informed it can't be used because it changes a published interface which isn't allowed. I have been given a pointer by Noel to create an XDispatchInformationProvider2 interface which extends XDispatchInformationProvider. I think this is what Maxim was also referring to in Comment 1. I have started looking how to do this.
I have brought my original patch for this out of abandoned state and have submitted a revised patch that tries to address review concerns of the original effort. The patch is having trouble getting past Jenkins though. Visual studio keeps complaining about casting error. I've tried a couple different things but no luck. It passes clang and gcc builds just fine.