Bug 158101

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'."