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
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)
Dear Yousuf Philips (jay) (retired), To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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.