Created attachment 190702 [details] Screenshot of the problem on Windows When opening the popup menu in an empty Writer or Calc document, all disabled entries are visible, which makes the menu loooong and kinda difficult to use. 1. Open a new empty document 2. Right click -> very tall popup menu. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 41d9584179ef7b4e18eda47c2c0a955df8c087a5 CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: x11 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded and qt5, but not with GTK3 plugin. Also on Windows. bibisect-242-win shows this seems to have started with: https://git.libreoffice.org/core/+/a0955317900075371d6adb7f924af24c22f02d09 author Jim Raykowski <raykowj@gmail.com> Fri Sep 15 21:26:32 2023 -0800 committer Jim Raykowski <raykowj@gmail.com> Wed Sep 27 07:12:30 2023 +0200 tdf#139935 Part B: Show all menu items possible/potential actions, Adding CC to: Jim Raykowski
While DontHideDisabledEntry could be set false to prevent the disabled context menu items from being shown, it would defeat the purpose of the regression causing patch. Here is a patch that provides gtk context menu behavior for non-gtk backends while preserving the intent of the regression causing patch: https://gerrit.libreoffice.org/c/core/+/159192
*** Bug 158596 has been marked as a duplicate of this bug. ***
I notice this on Windows. I thought it's a change in 24.2, but not very useful to see what is not available anyway.
(In reply to Jim Raykowski from comment #1) > Here is a patch that provides gtk context menu behavior for non-gtk backends > while preserving the intent of the regression causing patch: > https://gerrit.libreoffice.org/c/core/+/159192 Seems like UXEval is needed here to facilitate a way forward
Created attachment 191837 [details] win vs. gtk3 DontHideDisabledEntry false (top) vs. true (bottom) and win (left) vs. gtk3 (right) Disabled entries should be shown, hidden not. Cut/Copy is usually always available but temporarily not on empty text => disabled. Interactions with section, hyperlinks, fields etc. only possible if the context is appropriate => hide otherwise. Bug 139935 was about "Insert menu in Master Navigator context menu should "deactivate/grey out" Text as an option when Text is the selected item", which I'd expect to be set in some *State function. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b72aa31d7db38c81f757206e4e51844b839797ea CPU threads: 16; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win Locale: de-DE (en_DE); UI: en-US Calc: threaded Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4a3804743645730dbb6dda21eacd1c3c93f85509 CPU threads: 32; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: de-DE (en_US.UTF-8); UI: en-US Calc: threaded
(In reply to Heiko Tietze from comment #5) > Disabled entries should be shown, hidden not. The popup menu in the attachment is an XML file with UNO commands (defined in swriter/popupmenu/text.xml). AFAIK, we can only enable/disable UNO commands in such menus... there's no way to hide a UNO command in such menus. At least not in a GetState function. Also, I have the feeling that over time, devs have always assumed that a disabled UNO command will be hidden, which is why the text.xml menu is so gigantic. If we leave all disabled UNO commands visible, we'll get enormous menus everywhere, full of disabled items. (In reply to Jim Raykowski from comment #1) > Here is a patch that provides gtk context menu behavior for non-gtk backends > while preserving the intent of the regression causing patch: > https://gerrit.libreoffice.org/c/core/+/159192 Therefore, I believe the patch proposed by Jim is valid.
(In reply to Rafael Lima from comment #6) > AFAIK, we can only enable/disable UNO commands in such menus... Which is wrong and should be fixed. > Therefore, I believe the patch proposed by Jim is valid. At least it is an improvement.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1ac7350a7032a760be22cce845eab7efe435827d tdf#158101 Make non-gtk backends context popup menu item It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
It's now OK with: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 379968864c42f4bd99d874a4ce1949dd6eed45b8 CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: CL threaded This should be cherry-picked for 24.2.
*** Bug 159487 has been marked as a duplicate of this bug. ***
Jim Raykowski committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/2212b3d09bbd09a7a70095c18e8f43cd4b2019d5 tdf#158101 Make non-gtk backends context popup menu item It will be available in 24.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 159898 has been marked as a duplicate of this bug. ***
On Heiko's comment 5: > DontHideDisabledEntry false (top) vs. true (bottom) [...] > > Disabled entries should be shown, hidden not. I stumbled upon "DontHideDisabledEntry" through duplicate bug 159898... and left this comment about the advanced setting's current name: - - - Weird, do these Expert configs usually have "double negatives"? - "Hide Disabled Entry" = Enabled means "YES hide" = Disabled means "NO hide" vs. the current: - "Don't Hide Disabled Entry" = Enabled means "YES DO NOT hide!" = Disabled means "NO DO NOT hide!" The current wording seems pretty confusing to me. - - - (Should something like this be marked as a separate bug report / enhancement request? Or is it better to have it where the initial patches were?)
(In reply to Tex2002ans from comment #13) > Weird, do these Expert configs usually have "double negatives"? Nope, but no one to blame (in the last 20 years). Coming from the fact that you hide the idea for the label could be don't hide. But as you mention it's good practice to positively name functions. The HIG on menus states "Turning on an item in the menu should always enable the option. Negative options create a double negative which can be confusing. For example, use 'Show hidden files' instead of 'Hide hidden files'."