+++ This bug was initially created as a clone of Bug #2033572 +++

1. Proposed title of this feature request
[RFE] Provide options to edit and add to the right-click menu

2. Who is the customer behind the request?
Account: Asml 6266137
TAM customer: yes
CSM customer: yes
Strategic: yes

3. What is the nature and description of the request?
ASML want to be able to customize the right-click menu.
They would like to see a feature were they can easily modify the right-click menu

4. Why does the customer need this? (List the business requirements here)
ASML see this a desired workflow. It makes navigation easier.
This is also inline with their desire to stay close to the feature as provided by the LXDE desktop from which they are migrating from

5. How would the customer like to achieve this? (List the functional requirements here)
ASML would like to achieve this with a drop in configuration file.
Making it practical to maintain and also easy to provide individual users with their own custom menus.

6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
After configuration is completed, on the desktop right-click should display the customer menu items

7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
no
8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL8, RHEL9)?
ASAP RHEL8
9. Is the sales team involved in this request and do they have any additional input?
NO
10. List any affected packages or components.
nautilus
11. Would the customer be able to assist in testing this functionality if implemented?s
Yes

--- Additional comment from RHEL Program Management on 2021-12-17 09:39:35 UTC ---

The keyword FutureFeature has been added. If this bug is not a FutureFeature, please remove from the Summary field any strings containing "RFE, rfe, FutureFeature, FEAT, Feat, feat".

--- Additional comment from Ondrej Holy on 2022-01-05 08:19:04 UTC ---

Is this bug about a file manager or a desktop? Because the context menu for the desktop is provided by the gnome-shell, or maybe by the gnome-shell-extensions component depending on whether the desktop-icons extension is enabled.

--- Additional comment from Anthony Russell on 2022-01-05 10:36:59 UTC ---

Hi Ondrej,

The customer would like this functionality on the desktop, not the file manager.
For example, they are on a blank desktop. They right click. This takes them to a menu that they customized for this specific user. The menu provides applications and sub menus that this specific user needs.
Different users may have different menus.
Does this answer you question?

--- Additional comment from Ondrej Holy on 2022-01-05 14:37:25 UTC ---

So this is for gnome-shell-extensions component probably, not for nautilus. There are already some GNOME extensions to create custom menus, perhaps some of them could be used, or should not be that hard to create some...

--- Additional comment from Anthony Russell on 2022-01-06 12:51:59 UTC ---

Thanks Ondrej,

Do you have any extensions I could suggest to the customer that they could look into?

--- Additional comment from Ondrej Holy on 2022-01-07 14:38:59 UTC ---

I've found e.g. https://extensions.gnome.org/extension/4295/custom-menu-panel/ which creates a custom menu in the top bar and is fully configurable over .json file. But this won't work out-of-box with the gnome-shell version in RHEL 8. I think it should not be hard to adapt this, but this is rather a question for Florian...

--- Additional comment from Anthony Russell on 2022-01-10 07:52:43 UTC ---

Hi Ondrej,

Do you think this could be customizable right click menu? Because that is the main request from the customer.

--- Additional comment from Ondrej Holy on 2022-01-10 12:36:09 UTC ---

After a brief reading of the attached customer case, I got the impression that a custom menu in the top bar would also be a possibility, but I was probably wrong. Anyway, I think it should not be such a big deal to create such an extension (e.g. Desktop Icons extension also modifies the right-click menu). But again, this is a question for Florian, not me.

--- Additional comment from Anthony Russell on 2022-01-18 11:13:43 UTC ---

Thanks Ondrej,

I discussed the case with the CU last week.
They were happy your willingness to provide suggestions.
But they would like to know if this a valid request/RFE. Could we respond to this?

--- Additional comment from Anthony Russell on 2022-04-20 10:37:33 UTC ---

Hi Ondrej, Florian,

Are there any suggestions on how to further approach this?
This is a hot topic for the customer 

Cheers,

Anthony

--- Additional comment from Anthony Russell on 2022-04-26 15:19:31 UTC ---

Hi,
I spoke to the customer today.
They would really like more details on how they could address this.
Are the specific things you need from them?
They are will to test any suggestion you have.
Do you have anything I can share with the customer?

--- Additional comment from Tomas Popela on 2022-04-26 16:47:22 UTC ---

(In reply to Anthony Russell from comment #11)
> Hi,
> I spoke to the customer today.
> They would really like more details on how they could address this.
> Are the specific things you need from them?
> They are will to test any suggestion you have.
> Do you have anything I can share with the customer?

Anthony, you do have an update from Bob from Thursday that you've replied to yesterday. There isn't any new update.

--- Additional comment from Anthony Russell on 2022-05-03 07:32:29 UTC ---

This is a document from ASML describing in short statements what their desktop requirements.
Item 6 is relevant for this RFE.
6] Three-word summary: Overwrite right-click menu

--- Additional comment from Anthony Russell on 2022-05-03 07:39:35 UTC ---

Video demo of ASML desktop requirements.
Right click menu part start at 5:21

--- Additional comment from Anthony Russell on 2022-05-03 07:46:51 UTC ---

I have added two attachments with more details on what the customer would like to see.
Do you think that the custom panel extension mentioned in comment #6, when modified, would be able to achieve this?

--- Additional comment from Florian Müllner on 2022-05-30 18:27:25 UTC ---

(In reply to Anthony Russell from comment #15)
> Do you think that the custom panel extension mentioned in comment #6, when
> modified, would be able to achieve this?

My impression is that they are using desktop icons, which already replaces the menu. So unless they are willing to choose between desktop icons and customizable background menu, both functionalities would need to be provided by a single extension.

The best option for that would likely be a modified desktop-icons extension. I don't see how upstream would be interested in that functionality, so this would have to be a downstream patch we carry in RHEL.

Also the desktop-icons upstream focuses on "desktop-icons-ng" these days (a combo of a GTK application that implements desktop icons, and a small extension that makes sure the window behaves like a desktop (keeping it at the bottom of the stack, on all workspaces, invisible in overview, ...). If we adopt that approach in future RHEL versions, the downstream work would have to be done again from scratch (this time in an GTK applications instead of a shell extension).

--- Additional comment from Anthony Russell on 2022-06-07 09:47:22 UTC ---

@fmuellner 
Thank you for the update.
From your update I am getting the impression that this is not going to be easy.
If I understand you correctly we would need to provide/modify two extensions. And because you don't think upstream is going to be very interested in these changes we will need to maintain those downstream.
This leaves me worried that the likelihood that we can deliver this not very high.

A little background from the customer.
What the customer needs is a right-click customizable menu. This means that if a user right-clicks anywhere on the desktop they get a menu that is tailored to there specific needs.
Why do the need this?
The customer is a chip manufacturer. Of better yet. They make the machines that chip manufacturers use to make their chips.
Their desktop is intended to be used in a clean room and is the interface to the machine that makes the chips. The clean room is the room where chip manufacturers engineers work. The movements of these engineers are confined by the clean suits the must wear. In this environment efficient in movement is vital. So the ability the quickly navigate using the right click menu is considered of very high priority and a big part of the daily workflow.


So what do you need from the customer to move this forward? If I understand you correctly decisions need to be taken to define how to proceed.

--- Additional comment from Florian Müllner on 2022-06-15 13:37:15 UTC ---

(In reply to Anthony Russell from comment #17)
> From your update I am getting the impression that this is not going to be
> easy.

Much depends on the exact scope:

 - a list of label → commandline pairs would be relatively straight-forward
 - context-dependent menus would add more complexity (need a way to express
   context in the format, and a way to pass the right-clicked item to relevant
   actions)
 - more than one level of nesting would require a new submenu implementation
   that isn't provided by gnome-shell (that is, gnome-shell supports menu→submenu,
   but not menu→submenu→submenu etc.)
 - if some actions cannot be implemented by external commands, but require
   injecting custom javascript code into gnome-shell, that would add more
   complexity


> If I understand you correctly we would need to provide/modify two
> extensions.

No, off-hand it involves only one extension: The existing desktop-icons
extension that we provide in RHEL.

The second extension I mentioned - desktop-icons-ng (next generation) - is
what upstream is focusing on nowadays. There context menus are *not* provided
by the extension, but by a small GTK application.

If we ever switch to desktop-icons-ng, then we would need to reimplement the
custom menu support in the GTK app. But note that such a switch would only
occur in a major RHEL update, so RHEL 10 at the earliest (and so far there
are no plans).


> And because you don't think upstream is going to be very
> interested in these changes we will need to maintain those downstream.

That is my assessment, yes.


> So what do you need from the customer to move this forward? If I understand
> you correctly decisions need to be taken to define how to proceed.

As outlined above, a lot depends on the actual scope.

 - what kind of items (just commandlines, or different types like
   commands, .desktop files, custom gnome-shell code)
 - do they want a single menu, or different menus depending on
   context (that is, do they want to replace the menu that
   appears when clicking on the background, or also the context
   menus when right-clicking a desktop icons)
 - how deep do they want menus to nest

As we are talking about a downstream modification (read: all support is
entirely on us), limiting the scope as much as possible would be helpful.

--- Additional comment from Matthias Clasen on 2022-06-24 14:40:58 UTC ---

Florian,

can you provide some detailed instructions for ASML to 
try the https://extensions.gnome.org/extension/4295/custom-menu-panel/ extension in RHEL8 ? I assume they need to remove the desktop icons extension first, and then install this one? How is it configured?

--- Additional comment from Florian Müllner on 2022-06-27 13:36:37 UTC ---

I was asked to provide instructions for using the custom-menu-panel extension (https://extensions.gnome.org/extension/4295/custom-menu-panel/) in RHEL8. Here are my findings:

The oldest version the extension claims to support is GNOME 40 (RHEL9), but in reality it works as expected on older versions, including RHEL8.

By default, gnome-shell does accept extensions that don't explicitly support the GNOME version in use, so the extension should work out of the box.

To make sure that is the case, check that

  $ gsettings get org.gnome.shell disable-extension-version-validation

returns "true".

If it doesn't, the value can be changed with the following command:

  $ gsettings set org.gnome.shell disable-extension-version-validation true

Alternatively, edit the extension's metadata.json file to include "3.32" in the "shell-version" array.


The extension reads its menu definition from a ".entries.json" file in the user's $HOME.

The root object should have an "entries" property that contains an array of objects that describe menu items.

Each menu item has a "type" property that describes the item type:

 - launcher
   A regular, stateless item that runs a command when activated.

   It is defined by the following properties:
   - title - the menu item label
   - command - a shell command line to run if the item is activated

 - toggler
   A menu item with an on/off state (represented by a switch)

   It is defined by the following properties:
   - title - the menu item label
   - command_on - a shell command line to switch the item on
   - command_off - a shell command line to switch the item off
   - detector - a shell command for determining the initial state

   According to the documentation, the "detector" command should return
   0 for "on" and non-0 for "off". However in reality
     - the command isn't run at all (unless manually patching the extension)
     - the state actually depends on whether the command returns any output

 - submenu
   An expandable item that reveals additional menu items when activated

   It is defined by the following properties:
   - title - the menu item label
   - entries - an array of menu items, just like the top-level property

   The format allows for nested submenus, but the implementation does not.

 - separator
   A non-interactive item to visually separate menu sections from each other.


The following is an example configuration that contains at least one item of each type:

```
{
    "entries": [
        {
            "type": "submenu",
            "title": "Clock",
            "entries": [
                {
                    "type": "toggler",
                    "title": "Show Seconds",
                    "command_on": "gsettings set org.gnome.desktop.interface clock-show-seconds true",
                    "command_off": "gsettings set org.gnome.desktop.interface clock-show-seconds false",
                    "detector": "gsettings get org.gnome.desktop.interface clock-show-seconds | grep true"
                },
                {
                    "type": "toggler",
                    "title": "Show Weekday",
                    "command_on": "gsettings set org.gnome.desktop.interface clock-show-weekday true",
                    "command_off": "gsettings set org.gnome.desktop.interface clock-show-weekday false",
                    "detector": "gsettings get org.gnome.desktop.interface clock-show-weekday | grep true"
                }
            ]
        },
        {
            "type": "separator"
        },
        {
            "type": "launcher",
            "title": "Edit menu",
            "command": "gedit $HOME/.entries.json"
        }
    ]
}
```

--- Additional comment from Florian Müllner on 2022-06-27 13:39:58 UTC ---

(In reply to Matthias Clasen from comment #19)
> I assume they need to remove the desktop icons extension first

The custom menu is added to the top bar, before the system status menu. That doesn't match what the client is asking for, but has the advantage that it doesn't conflict with desktop-icons or any other extension.

--- Additional comment from Florian Müllner on 2022-06-27 18:13:00 UTC ---

I've uploaded a modified version of the extension that
 - runs the 'detector' script to fetch the initial state
 - replaces the background menu instead of adding a custom indicator to the top bar

It is available at https://fedorapeople.org/~fmuellner/custom-menu-panel@AndreaBenini.shell-extension.zip.

Note that the extension only works with gnome-shell's own background menu. That is, it only works in the regular (non-classic) session with the desktop-icons extension disabled.

--- Additional comment from Tomas Popela on 2022-08-26 09:31:13 UTC ---

Can we please try to get some update from the customer?

--- Additional comment from Anthony Russell on 2022-09-27 11:07:47 UTC ---

Hi Tomas,

I discussed this with the customer last week.
They were able to followup and test your suggestions.
The feedback from the customer is that this works for them.
And they would like to know when this can be incorporated into the regular rhel release.
Let me know if you need anymore information from them.

Cheers,

Anthony

--- Additional comment from Anthony Russell on 2022-10-03 09:58:07 UTC ---



--- Additional comment from Anthony Russell on 2022-10-03 09:59:08 UTC ---



--- Additional comment from Anthony Russell on 2022-10-03 10:03:29 UTC ---

@fmuellner @tpopela 

The customer just sent me an update.
===
We used modified version of GNOME shell plugin which is provided by you, on our desktop.
Everything was fine until we populated menus with 35 entries (this is actual amount of entries in our product).
In this case, we could not display all the entries on our menu which is expected. But, in this case we need a vertical scroll-bar to navigate
down to see and pick rest of the entries.
===

Is there a way for the customer to add a scrollbar?

--- Additional comment from Florian Müllner on 2022-10-03 13:08:36 UTC ---

(In reply to Anthony Russell from comment #27)
> @fmuellner @tpopela 
> 
> Is there a way for the customer to add a scrollbar?

Submenus already have scrolling ability, but part of it depends on code from top bar menus. The downstream patches that move the menu from the top bar to the background will have to replicate that functionality (basically: setting a maximum height to which the menu is allowed to grow before scrolling kicks in).

--- Additional comment from Anthony Russell on 2022-10-04 10:31:43 UTC ---

@fmuellner @tpopela 

Thank you for the update.
I sent the details to the customer, he reports that he does not exactly know how to set maximum height.
Could you please provide more details and maybe an example of this.

Cheers,

Anthony

--- Additional comment from Tomas Popela on 2022-10-04 10:41:35 UTC ---

(In reply to Anthony Russell from comment #29)
> Thank you for the update.
> I sent the details to the customer, he reports that he does not exactly know
> how to set maximum height.
> Could you please provide more details and maybe an example of this.

What Florian was saying that there is a missing functionality/bug in the extension's code that needs to be addressed. Customer can't do anything it themselves.

--- Additional comment from Anthony Russell on 2022-10-04 10:53:33 UTC ---

@tpopela @fmuellner 

I am sorry, I completely misunderstood that. 
So what can we done for the customer.
This is a pretty big deal for them.
Is this something that can be easily fixed?

--- Additional comment from Tomas Popela on 2022-10-04 11:01:42 UTC ---

(In reply to Anthony Russell from comment #31)
> @tpopela @fmuellner 
> 
> I am sorry, I completely misunderstood that. 
> So what can we done for the customer.
> This is a pretty big deal for them.
> Is this something that can be easily fixed?

Anthony, please stop for a moment. What we've handled to the customer in https://bugzilla.redhat.com/show_bug.cgi?id=2033572#c22 is a development version - not bound to any support - and IT'S EXPECTED that there might be issues as what the customer is asking for is very specific to them. Florian will address the problems when get will have time again to look at this bug and will provide them with another development version of the extension (again with NO support - it will be supported only when it's ready and gets into RHEL). Also what was mentioned in the comment #28 was not really anything to be shared with the customer - it was an internal note - mainly for Florian to not forget about it.

--- Additional comment from Anthony Russell on 2022-10-04 12:00:52 UTC ---

@tpopela 

Thank you for the update.
I apologize if I came across as to pushy. That was not my intention.
I just wanted to understand if this was something the could be fixed/addressed.
I really to understand that this unsupported and this has been communicated to the customer.
I would also like to express my appreciation of the effort so far. I know that this is not the regular way of doing things.


Regards,

Anthony

--- Additional comment from Tomas Popela on 2022-10-04 12:05:47 UTC ---

Please don't use needinfo unless it's really needed (using "@" to mention the people automatically adds the needinfo).

--- Additional comment from Florian Müllner on 2022-10-04 13:56:25 UTC ---

(In reply to Anthony Russell from comment #33)

> I just wanted to understand if this was something the could be
> fixed/addressed.

Yes. I've uploaded a new version at https://fedorapeople.org/~fmuellner/custom-menu-panel@AndreaBenini.shell-extension.zip now.

--- Additional comment from Anthony Russell on 2022-10-06 07:13:43 UTC ---

Thank you very much.
I have passed it on to the customer.

--- Additional comment from Anthony Russell on 2022-10-06 09:30:09 UTC ---

The customer quickly tested the new version.
They can confirm that it now works as expected for them.

Again, thank you very much for the quick update.
It is truly appreciated.

--- Additional comment from Anthony Russell on 2022-10-10 07:31:17 UTC ---

The customer has tested the new version of the extension and confirm that it works well.
They have a few additional request:
===
On the Desktop right-click menu we need to see this example structure;
1) A common.json file will provide some generic menu group names and items into it.
2) We want to plug another menu config file (ie. layer1.json) to common.json for per platform (platformX, patformY..etc)
3) Finally our customer can easily add their own menu groups and items on top/bottom or inside of ours (customer.json)

Can we do this with the custom-menu-panel GNOME shell extension?
===

I know the work down so far is all best effort" and not officially supported. I appreciate you have gone above and beyond to help this customer.
So my question regarding the new requests for now is just , is this technically feasible with this extension?

--- Additional comment from Tomas Popela on 2022-10-10 07:46:07 UTC ---

(In reply to Anthony Russell from comment #38)
> The customer has tested the new version of the extension and confirm that it
> works well.
> They have a few additional request:
> ===
> On the Desktop right-click menu we need to see this example structure;
> 1) A common.json file will provide some generic menu group names and items
> into it.
> 2) We want to plug another menu config file (ie. layer1.json) to common.json
> for per platform (platformX, patformY..etc)
> 3) Finally our customer can easily add their own menu groups and items on
> top/bottom or inside of ours (customer.json)
> 
> Can we do this with the custom-menu-panel GNOME shell extension?
> ===
> 
> I know the work down so far is all best effort" and not officially
> supported. I appreciate you have gone above and beyond to help this customer.
> So my question regarding the new requests for now is just , is this
> technically feasible with this extension?

I have to say that I'm really not personally happy about the direction where this RFE is going. From the initial request this keeps growing into a state that if specified initially we would decline it immediately as this is getting way too specific for needs of one particular customer.

My suggestion to the customer is to write their own tooling that would prepare the final JSON file ("~/.entries.json") according to their needs.

--- Additional comment from Anthony Russell on 2022-10-10 10:40:57 UTC ---

Thanks Tomas,
I understand. This is a customer that can be demanding at times.
If this is something that is just to specific, then that is good argument that I can clearly communicate to them and what they should be able to understand.
But, I will wait before communicating anything to them.

Cheers

--- Additional comment from Anthony Russell on 2022-10-14 12:00:13 UTC ---

Additional explanation on what the customer would like.
I have of communicated that this depends on if this is even possible.
And that you guys will need to decide on how to proceed.

===
This will be main folder which all menus will collected there: $HOME/.gnome.menus.d/
$HOME/.gnome.menus.d/00-common.json will show first group of menus
$HOME/.gnome.menus.d/01-platformX.json will show second group of menus
$HOME/.gnome.menus.d/02-custom.json will show third group of menus. Our customer can be easy edit this file.
If one of that file missing, right-click menu can be shown using existing .json files.
This approach is not conflicts previous message I sent. Now, I just sent to show what we expected more clearly.
===

Also it is OK for us to re-use existing "/usr/local/share/applications/item???.desktop" file to show desktop right-click menus which we currently use on our Start-Menus.
Each menu item placed on a separate "itemX.desktop" file as you can see.
---
[Desktop Entry]
Type=Application
Categories=GNOME;GTK;System;ASML-Tools;
Name=Menu Item01
Exec=/usr/share/bin/asmlcommand01
Terminal=false
StartupNotify=true

--- Additional comment from Florian Müllner on 2022-10-19 14:33:13 UTC ---

(In reply to Anthony Russell from comment #41)

> This will be main folder which all menus will collected there:
> $HOME/.gnome.menus.d/
> $HOME/.gnome.menus.d/00-common.json will show first group of menus
> $HOME/.gnome.menus.d/01-platformX.json will show second group of menus
> $HOME/.gnome.menus.d/02-custom.json will show third group of menus. Our
> customer can be easy edit this file.
> If one of that file missing, right-click menu can be shown using existing
> .json files.

That requires a rewrite of the configuration loading code. Worse, the setup is so specific (defined set of files, special handing when a file is missing) that I don't see how it would be acceptable upstream. That is, we'd not only have to write the code, but also maintain it downstream.


> Also it is OK for us to re-use existing
> "/usr/local/share/applications/item???.desktop" file to show desktop
> right-click menus which we currently use on our Start-Menus.
> Each menu item placed on a separate "itemX.desktop" file as you can see.

It's unclear to me what exactly is meant here.

If it is about adding a new launcher type that picks up command and title from a .desktop file, then that seems like a reasonable addition to me (albeit still requires writing the code).

If it is about picking up .desktop files with a particular naming scheme and adding them automatically to the entries generated from the json configuration, then that would again be way to specific to the customer setup.

--- Additional comment from Tomas Popela on 2023-01-12 16:33:58 UTC ---

We had a chance to talk about this with Matthias and Florian and we've agreed that we will incorporate the version from https://bugzilla.redhat.com/show_bug.cgi?id=2033572#c35 (that we had positive feedback on from the customer) into the gnome-shell-extensions (it MIGHT get into RHEL 8.8, but that will depend on Florian's time as we do only have 6 weeks to get anything into RHEL 8.8). We are also declining any feature requests that were raised in comments starting with https://bugzilla.redhat.com/show_bug.cgi?id=2033572#c38 - the reasons mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=2033572#c39 still apply.