Bug Hunting Session
Bug 112620 - Function lists in Customize dialog not being filtered by configuration settings
Summary: Function lists in Customize dialog not being filtered by configuration settings
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Customize-Dialog 113828
  Show dependency treegraph
 
Reported: 2017-09-24 15:33 UTC by Yousuf Philips (jay) (retired)
Modified: 2019-01-09 09:35 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2017-09-24 15:33:42 UTC
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[1] 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[2] ( 'Draw Functions' in Drawing category ), which is set to not appear in the keyboard tab, but it does.

[1] https://opengrok.libreoffice.org/xref/core/svx/sdi/svx.sdi#542
[2] https://opengrok.libreoffice.org/xref/core/svx/sdi/svx.sdi#2301
Comment 1 Maxim Monastirsky 2017-09-24 18:03:57 UTC
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
Comment 2 Heiko Tietze 2019-01-06 19:14:34 UTC
It's a core function, admittedly not critical but still relevant. So I'd treat this as a major bug with high importance.
Comment 3 Jim Raykowski 2019-01-09 01:47:59 UTC
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/
Comment 4 Heiko Tietze 2019-01-09 08:45:00 UTC
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)
Comment 5 Jim Raykowski 2019-01-09 09:35:50 UTC
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.