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 [1]. The current implementation on the application side is that if one of those *Config booleans is true, the command will be returned via XDispatchInformationProvider [2][3], 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.

[1] https://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1frame_1_1XDispatchInformationProvider.html
[2] https://opengrok.libreoffice.org/xref/core/sfx2/source/appl/appdispatchprovider.cxx#207
[3] https://opengrok.libreoffice.org/xref/core/sfx2/source/view/sfxbasecontroller.cxx#1143

It's a core function, admittedly not critical but still relevant. So I'd treat this as a major bug with high importance.

Hi All,

By working on a patch for this I am gaining some understanding of idl. Here is a patch for review. 

https://gerrit.libreoffice.org/#/c/65990/

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.

Hi All,

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.

https://gerrit.libreoffice.org/#/c/65990/

*** Bug 130406 has been marked as a duplicate of this bug. ***

(In reply to Jim Raykowski from comment #6)
> https://gerrit.libreoffice.org/#/c/65990/
Bug 130405 arose from being a naive user, trying to customize the Styles menu. 
In relation to the discussion here, bug 130405 is a case where the same command may be legitimate both in menu and toolbar, but in the cases described in that bug, the labels were different.  This comment is just to give a "heads up" that there might be an issue with labels between toolbars and menus. Wiser persons must say whether there should be consistency between menu/toolbar labels for the same .uno commands, or if your patch can also handle (will show) difference in labels.    (was helpful to have "tooltips" on the commands in Customize - from your other patch)

Reported in bug 147411 that all *CONFIG flags have to be set to effectively hide an item from the customization. They are not independent from each other.